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Introduction 

Health  Information  Technology  (HIT)  systems  should  facilitate  the  collection  and  point-of-care  access 
to  accurate,  comprehensive,  contextually  rich  clinical  data  for  all  acuity  levels  of  healthcare.  Open 
platforms  of  plug-and-play  medical  devices  and  HIT  systems  could  enable  improved  quality  and 
timeliness  of  data  access,  as  well  as  cost-effective  development  of  innovative  medical  “apps”  for 
diagnosis,  treatment,  research,  safety  and  quality  improvements,  health  technology  management,  and 
adverse  event  detection  and  reporting. 

The  Medical  Device  “Plug-and-Play”  (MD  PnP)  Interoperability  program  was  established  in  2004  to 
lead  the  development  and  adoption  of  open  standards  and  related  technologies  in  order  to  achieve 
this  vision.  The  MD  PnP  program  is  based  at  the  Massachusetts  General  Hospital  (MGH)  Dept,  of 
Anesthesia,  Critical  Care,  and  Pain  Medicine,  CIMIT  (Consortia  for  Improving  Medicine  with 
Innovation  &  Technology),  and  Partners  Healthcare  System,  with  foundational  support  from 
USAMRMC  (initially  through  TATRC  -  the  U.S.  Army  Telemedicine  &  Advanced  Technology 
Research  Center).  The  clinically  grounded  MD  PnP  program  has  taken  a  multi-faceted  approach  to 
address  key  barriers  to  achieving  interoperability,  including  the  development  and  subject  matter 
expertise  resourcing  of  suitable  open  standards  (e.g.  ASTM  F2761-09(13)  for  the  Integrated  Clinical 
Environment,  or  “ICE”);  the  elicitation,  collection  and  modeling  of  clinical  use  cases  and  system 
engineering  requirements  for  an  open  architecture  instantiation  of  ICE  as  a  platform  and  “ecosystem”; 
alignment  of  clinical  organizational,  manufacturer,  and  FDA  regulatory  expectations;  and 
implementation  of  prototype  use  cases  in  an  open  “sandbox”  or  testbed  environment. 

The  MD  PnP  program  has  built  a  geographically  dispersed,  interdisciplinary,  multi-institutional  team  to 
develop  and  implement  a  strategy  to  address  historical  barriers  and  accelerate  the  achievement  of 
safe  device  interoperability  through  collaboration.  Since  the  program’s  inception,  more  than  1000 
clinical  and  engineering  experts,  and  representatives  of  more  than  150  companies  and  institutions 
have  participated  in  our  plenary  workshops,  conferences,  working  group  meetings,  lab 
demonstrations,  and  focus  groups  to  contribute  to  ongoing  program  activities  that  helped  shape  the 
common  goals.  Our  team  of  collaborators  has  included  participants  from  healthcare  delivery 
organizations  (e.g.  Kaiser  Permanente,  Johns  Hopkins  Medicine,  University  of  Florida  Hospital,  VHA), 
federal  agencies  (including  the  FDA,  NIST,  Military  Health  System,  and  NSF),  university  computer 
and  information  science  groups  (e.g.  Pennsylvania,  Illinois/Urbana-Champaign,  Kansas  State),  device 
manufacturers  (e.g.  Draeger  Medical  Systems,  Philips  Healthcare,  GE  Healthcare),  DocBox,  Moberg 
Research,  Anakena  Solutions,  large  technology  companies  (e.g.  Intel,  MITRE,  Lockheed  Martin),  and 
the  Partners  Healthcare  System  biomedical  engineering,  clinical,  and  information  systems 
communities  (Massachusetts  General  Hospital  and  Brigham  &  Women’s  Hospital  in  particular).  The 
collaborative  research  relationship  with  DocBox  has  proven  especially  productive. 

The  collaborative  work  of  the  MD  PnP  program  has  had  a  broad  impact,  and  USAMRMC  support  for 
MD  PnP  program  development  has  been  the  key  enabler  of  significant  progress  towards  the  goal  of 
achieving  medical  device  interoperability.  USAMRMC  funding  has  leveraged  additional  synergistic 
project-specific  funding  from  CIMIT,  NSF,  NIST,  and  NIH,  but  it  is  USAMRMC  funding  that  has 
uniquely  made  possible  our  program’s  enabling  efforts  that  are  moving  medical  device  interoperability 
and  patient  safety  forward  along  synergistic  streams  of  requirements,  consensus  standards,  platform 
development,  and  regulatory  science.  A  major  outcome  of  USAMRMC  funding  has  been  enabling  our 
team  to  form  and  grow  a  diverse  community  of  involved  and  committed  collaborators  and 
stakeholders.  Pertinent  examples  of  our  ability  to  coalesce  interest  and  commitment  around  an 
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important  issue  are  the  support  from  the  White  House  CTO,  HHS,  and  standards  bodies  for  improving 
the  clock  time  accuracy  of  medical  device  data  transmitted  to  EHRs,  and  the  2014-2015  Global  City 
Teams  Challenge  project  “Remotely  Caring  for  Our  Most  Vulnerable  Citizens  In-Place  During  a 
Pandemic,”  performed  with  DoD  collaborators  from  MHS,  DHA,  TATRC,  CERDEC,  and  Edgewood, 
as  well  as  the  FDA,  industrial  partners,  and  universities.  We  led  a  rapid  med-tech  response  to  improve 
the  safety  of  healthcare  workers  treating  patients  with  Ebola  Virus  Disease,  and  held  a  four-day 
“hackathon”  in  our  MD  PnP  Lab  where  twenty  collaborators  rapidly  prototyped  data  interoperability- 
based  innovations  by  leveraging  our  Lab  and  our  team’s  subject  matter  expertise. 

Body  of  Report 

This  award  reflected  new  and  emerging  technologies  and  research,  and  built  on  prior  and  current  MD 
PnP  program  work  (USAMRMC  awards  #W81XWH-06-1-0651  and  W81XWH-09-1-0705),  to  develop 
tools,  applications,  and  sharable  data  to  advance  the  state  of  the  art  of  medical  device  interoperability 
and  enable  a  broader  community  of  software  developers,  manufacturers,  regulators,  clinicians,  and 
standards  writers  to  implement  medical  device  interoperability. 

The  intent  of  our  research  for  this  funded  project  was  to  prototype  and  demonstrate  tools  to  further 
enable  Medical  Device  Interoperability,  especially  -  but  not  limited  to  -  Integrated  Clinical 
Environments  (ICE),  building  on  what  we  had  learned  in  our  NIH  Quantum  Medical  Device 
Interoperability  (QMDI)  cooperative  research  project.  This  USAMRMC  project  was  funded  for  a  base 
year  plus  two  option-years,  and  the  elapsed  period  of  performance  was  four  years  and  four  months 
(30  July  2012  -  30  November  201 6). 

Aims  and  sub-tasks  for  this  project  evolved  over  the  four  years  based  on  our  research  findings  and 
the  evolution  of  health  information  technology  (HIT)  during  this  period.  The  following  aims  and  sub¬ 
tasks  (updated  with  each  option-year)  have  been  edited  for  clarity  and  brevity: 

Aim  1 :  ICE  Data  Logger 

Develop  a  software  research  prototype  of  the  Data  Logger  component  conforming  to  the  ICE  standard 
(ASTM  F2761).  Data  logging  is  necessary  to  address  regulatory,  safety,  cybersecurity,  and  liability 
needs  regarding  networked  medical  device  systems,  and  will  improve  the  forensic  analysis  of  clinical 
adverse  events  and  near  misses. 

Base  Year  sub-tasks  (30  July  201 2-29  July  2013): 

•  Base  the  initial  prototype  on  requirements  identified  through  the  NIH  Quantum  U01  project 

•  Develop  an  event  recording  and  playback  capability  that  demonstrates  the  potential  for 
forensic  analysis  of  activity  in  networked  medical  device  systems,  as  well  as  improved  adverse 
event  analysis  (useful  for  hospitals,  FDA,  manufacturers) 

•  Investigate  the  implementation  of  the  FDA  Unique  Device  Identifier  (UDI)  as  it  evolves,  and 
inform  the  FDA  of  our  research  findings 

•  Assess  the  clinical  usefulness  of  the  Data  Logger  by  analyzing  simulated  adverse  events 

•  Publicly  disseminate  research  results 

Qption-Year  1  sub-tasks  (30  July  201 3-29  November  201 4): 

•  Collaborate  with  NIST  to  implement  the  NIST  research  prototype  Data  Logger  on  the  MD  PnP 
open  platform 

•  Improve  playback  to  support  adverse  event  analysis 

•  Continue  research  with  Unique  Device  Identifiers 

Qption-Year  2  sub-tasks  (30  November  201 4-30  November  201 6): 

•  Add  metadata  such  as  location  tracking  and  video  to  Data  Logger 

•  Connect  Data  Logger  information  to  Clinical  Scenario  Repository  to  demonstrate  automatic 
logging  of  relevant  clinical  events 
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•  Add  updated  version  of  medical  device-transmitted  Unique  Device  Identifier 

Aim  2:  Web-Based  Clinical  Scenario  Repository 

Develop  a  sharable  repository  of  Clinical  Scenarios  that  could  be  improved  through  better  medical 
device  and  health  IT  integration.  The  scenario  repository  will  provide  use  cases  to  inform  design  of  the 
Data  Logger,  and  can  eventually  be  used  by  researchers,  standards  developers,  regulators,  and 
manufacturers  to  create  innovative  medical  technology  solutions  for  intractable  clinical  problems. 

Base  Year  sub-tasks  (30  July  201 2-29  July  2013): 

•  Provide  a  web  portal  for  users  such  as  clinicians,  clinical  engineers,  and  other  users  to  enter, 
revise,  and  annotate  clinical  scenarios 

•  Design  database  back-end  and  administrative  system  to  organize  users  and  permissions 

•  Use  feedback  from  clinicians,  industry,  and  the  FDA,  NIST,  and  VA  to  enhance  usability 

•  Publicly  disseminate  details  of  repository 

Option-Year  1  sub-tasks  (30  July  201 3-29  November  201 4): 

•  Release  beta  version  of  Clinical  Scenario  Repository  to  collaborators  for  testing  and  feedback 

•  Gather  scenarios  and  feedback  from  collaborator  users  about  the  site  design  and  data 
collected 

•  Improve  the  site  to  incorporate  and  reflect  feedback 

Option-Year  2  sub-tasks  (30  November  201 4-30  November  201 6): 

•  Promote  Clinical  Scenario  Repository  website  to  potential  users 

•  Further  fine-tune  features  of  Repository  based  on  actual  experience 

•  Add  new  Repository  features  requested  by  users 

Aim  3:  Open  Source  Code  Dissemination 

Disseminate  open-source  code  developed  by  the  MD  PnP  program  and  collaborators,  including  the 
prototype  Data  Logger,  in  order  to  facilitate  further  development  by  others. 

Base  Year  sub-tasks  (30  July  2012  -  29  July  2013): 

•  Determine  appropriate  venues,  tools,  and  processes  for  releasing  code 

•  Help  interested  external  parties  to  obtain  code  and  documentation 

•  Manage  the  integration  of  external  code  that  is  received  into  official  releases 

Option-Year  1  sub-tasks  (30  July  201 3-29  November  201 4): 

•  Release  any  NIH/QMDI  app  deliverables  into  ICE  “AX”  (App  Exchange)  repository/community 

•  Present  work  at  open  source  conference  or  meeting,  and  invite  volunteers  to  contribute 

•  Develop  new  reference  implementation  apps  or  app  frameworks,  and  release  to  ICE  AX 
repository/community 

Option-Year  2  sub-tasks  (30  November  201 4-30  November  201 6): 

•  Promote  work  and  App  Exchange  to  medical  and  open-source  communities  via  publications 
and  workshops 

Aim  4:  ICE  External  Interface  Data  Transfer 

Identify  and  evaluate  external  interfaces  to  bi-directionally  transfer  medical  device  and  patient 
contextual  data  between  the  integrated  clinical  environment  and  external  systems  of  national  interest. 

Base  Year  sub-tasks  (30  July  201 2-29  July  2013): 
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•  Investigate  connectivity  to  the  VHA  Open  VistA  EHR 

•  Investigate  connectivity  to  the  Nationwide  Health  Information  Network  (NwHIN)  and  other 
appropriate  and  available  systems 

•  Publicly  disseminate  research  results 

Option-Year  1  sub-tasks  (30  July  201 3-29  November  201 4): 

•  Explore  feasibility  of  connecting  MD  PnP  Lab  to  hospital  clinical  information  systems  (CIS) 
such  as  MGH  test  Admission/Discharge/Transfer  (ADT),  Physician  Order  Entry  (POE),  and 
pharmacy  systems 

•  Prototype  connection  to  CIS  interfaces 

Option-Year  2  sub-tasks  (30  November  201 4-30  November  201 6): 

•  Demonstrate  capability  to  export  data  collected  by  an  ICE  App  (e.g.  Smart  Alarm)  into  format 
suitable  for  later  analysis 

Research  Accomplishments 

Data  Logger,  Aim  1:  Develop  a  software  research  prototype  of  the  Data  Logger  component 
conforming  to  the  ICE  standard  (ASTM  F2761). 

The  MD  PnP  team  compiled  an  initial  set  of  needed  attributes  and  technical  requirements  for  the  ICE 
Data  Logger  that  specify  what  data  will  be  recorded,  the  format  of  the  data,  the  time-stamping, 
cryptographic  considerations,  and  sequencing  of  data,  and  other  technical  details.  These 
requirements  also  inform  data  playback,  particularly  where  features  of  the  Data  Logger  will  influence 
what  playback  capabilities  are  possible. 

Requirements  were  based  upon: 

•  Content  from  the  Integrated  Clinical  Environment  (ICE)  standard  (ASTM  F2761-09) 

•  Experience  to  date  with  clinical  scenario  implementations  in  the  MD  PnP  Interoperability  Lab 

•  Work  with  our  collaborators  on  the  NIH  Quantum  Medical  Device  Interoperability  (QMDI) 
project 

•  Early  data  logger  concept  and  an  MD  PnP  paper  presented  at  the  International  Conference  on 
Biomedical  Ontologies 

•  Clinician  Interviews 

•  An  FDA  conceptual  design  for  a  stand-alone  device  data  log 

We  planned  to  build  a  Data  Logger  implementation  following  these  requirements,  with  the  expectation 
that  building  it  would  reveal  necessary  refinements  to  the  requirements,  resulting  in  future  iterations  of 
the  requirements  document.  We  have  updated  and  maintained  these  requirements  to  reflect  lessons 
learned  during  development,  as  well  as  changes  to  the  QMDI  requirements  that  specify  the  system  in 
which  the  Data  Logger  will  operate. 

Several  months  into  our  data  logger  research,  a  research  group  at  NIST  led  by  Dr.  Kamran  Sayrafian 
expressed  interest  in  collaborating  on  this  project,  using  NIST  internal  funding,  and  our  project  greatly 
benefited  from  this  collaboration.  Starting  with  documentation,  requirements,  and  guidance  from  our 
team,  NIST  surveyed  relevant  data  logger  work  in  avionics,  automotive,  and  other  domains  to  identify 
additional  requirements.  NIST  compiled  this  set  of  data  logger  requirements,  and  we  collaborated  on 
a  technical  white  paper  about  the  different  levels  or  modes  of  logging  that  an  ICE  Data  Logger  will 
need  to  support. 

This  detailed  comparison  with  other  data  loggers,  such  as  aircraft  flight  data  recorders  and  automotive 
loggers,  enabled  us  to  collaborate  with  NIST  to  leverage  their  unique  engineering  expertise  to  build  a 
set  of  requirements  to  feed  back  to  the  NIH-funded  QMDI  project  and  the  broader  community,  and  to 
use  for  development  of  an  ICE  Data  Logger  standard.  We  began  documenting  the  range  of  existing 
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data  logging  strategies  in  other  domains  -  especially  transportation  -  to  serve  as  design  inputs  for  our 
Data  Logger  and  to  serve  as  an  informational  resource  for  standards  development. 

We  worked  with  NIST  to  plan  their  implementation  of  a  research  data  logger  prototype  based  on  our 
program’s  OpenICE  open-source  ICE  platform.  This  logger  and  playback  prototype  was  based  on  our 
jointly  developed  requirements  documents,  and  built  using  NIST’s  Data  Flow  middleware  and  data 
collected  from  medical  devices  in  our  MD  PnP  Lab.  Studying  the  approaches  used  by  different 
manufacturers  to  log  data  from  legacy  equipment  can  provide  valuable  insights  about  the  state  of  the 
industry  and  technology,  and  refine  requirements  for  future  (fully  plug-and-play  interoperable) 
interfaces  and  data  logging  standards.  We  chose  to  collect  some  data  with  the  commercially  available 
Bedmaster  system,  which  can  collect  and  store  data  from  a  GE  medical  network  and  is  cleared  by  the 
FDA  for  this  use,  and  with  the  Cardio-Pulmonary  Corporation  (CPC)  Bernoulli  system,  which  is 
similarly  approved  by  FDA  for  the  purpose  of  collecting  data  from  a  variety  of  medical  devices. 

The  Bedmaster  and  CPC  integration  systems  impose  their  own  constraints  on  what  data  is  available 
and  on  the  data’s  timeliness.  To  create  data  for  NIST  to  use  in  developing  their  data  logger  prototype, 
we  configured  the  Bedmaster  system  and  the  CPC  system  to  log  the  data  and  then  export  the  data 
files  to  SourceForge,  where  the  data  were  available  for  NIST  and  were  publicly  available  for  the 
research  community.  During  some  of  the  sample  runs,  we  made  video  recordings  of  the  patient 
simulator  and  devices,  so  that  the  data  logger  playback  application  could  display  synchronized  video. 

This  prototype  implementation  (illustrated  in  Figure  1)  was  demonstrated  as  part  of  a  set  of  MD  PnP 
and  collaborator  demonstrations  held  at  NIH  on  August  21-22  2013,  attended  by  more  than  65 
government  representatives  including  MHS,  FDA,  NIST,  NSF,  NIH,  ONC,  and  others.  Feedback  from 
the  audience  at  the  August  demonstrations  made  it  clear  that  there  is  considerable  and  widespread 
interest  in  this  work. 


Figure  1:  The  ICE 
Data  Logger  & 
Playback 
Demonstration 
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DB  Traffic 

-  ■  ► 

Data  Model 
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Application 

EDITOR 

Server 

BACKEND 

[Glassfish] 

[  (Java  EE) 

Synchronized  video  may  be  important  for  revealing  clinical  context.  For  instance,  part  of  the  data 
logger  demo  at  NIH  included  a  scenario  in  which  the  patient  received  an  overdose  from  a  PCA  pump. 
The  device  data  shows  the  patient's  physiologic  response,  the  log  from  a  PCA  pump  would  show  that 
the  dose  request  button  was  pressed,  but  only  the  video  could  reveal  that  the  button  was  pressed  by 
someone  other  than  the  patient  (called  “PCA-by-proxy”).  Thus,  the  root  cause  of  the  patient's 
overdose  could  only  be  found  by  including  a  video  record  with  the  device  data. 
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We  investigated  Data  Logger  performance  testing  in  the  context  of  the  collaborative  NIST  prototype 
implementation,  as  NIST's  Data  Flow  System  is  designed  to  handle  extremely  large  amounts  of  data. 
Our  simulators  were  not  able  to  generate  enough  traffic  to  stress-test  the  NIST  middleware,  so  it  was 
more  than  sufficient  for  our  applications.  This  demonstrated  the  feasibility  of  different  software 
approaches  to  implementation  of  a  prototype  ICE  data  logging  system,  and  showed  that  one  could 
scale  performance  (e.g.  bandwidth)  based  on  the  software  design. 

For  the  next  Data  Logger  implementation,  we  built  preliminary  data  logging  functionality  on  the  RTI 
DDS  middleware  we  were  using  for  our  OpenICE  platform  development,  using  our  ICE  Equipment 
Interfaces.  DDS  is  an  open  middleware  standard  from  Object  Management  Group  (OMG).  The  DDS 
implementation  we  used  was  developed  by  Real-Time  Innovations  (RTI),  and  is  used  extensively  in 
DoD  applications  like  ship  “command  and  control”  networks  and  drone  avionics.  These  applications 
require  high  performance  and  reliability,  and  RTI  has  extensively  tested  the  performance  of  the 
middleware.  We  worked  with  RTI  to  make  their  tools  freely  available  to  our  community  through  an  ICE 
Community  License. 

We  were  able  to  successfully  log  data,  as  illustrated  in  the  screen  shots  in  Figures  2  and  3.  Figure  2 
shows  an  application  that  displays  data  on  the  network  in  real  time.  This  application  can  also  be  used 
to  record  the  data  to  a  file. 


Figure  2.  Data  Logging  Application 
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MDC_FAST.STATUS 
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MDC_PULS_RATE_NONJNV 
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0.0 
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120.0 
95.0 
69.0 
66.0 
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70.0 
n  n 


[  unique.device.identifier 

ickOIRhDOpJf21FuL13RzHONbJnlde6IACce8 

|ckOIRhDOpJf21FuL13R2HONbJnlde6IACce8 

ickOIRhDOpJf21FuL13RzHONbJnlde6IACce8 
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MDC.PRESS.BLD 

MDC.PULS.OXIM.PLETH 
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MDC.PRESS.BLD 

MDC.ECG.AMPL.ST.III 

MDC.PRESS.BLD.  ART.ABP 

MDC.CAPNOGRAPH 

MDC.ECG.AMPL.ST.il 

MDC.ECG.AMPL.ST_I 


[0.0.0.0,0.0,0.0,0.0,0.0.0.0.0 

[337.0,337.0,337.0,337.0,33 

[195.0,197.0,199.0,200.0,20 

[2846.0,2774.0,2695.0,2611 

[241.0,242.0,242.0,242.0,24 

[502.0,502.0,502.0,502.0,50 

[8193.0,8193.0,8193.0,8193 
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Figure  3  shows  the  logged  data  for  a  waveform.  Figure  4  shows  a  capture  from  an  engineering 
prototype,  containing  samples  of  data  from  several  devices.  This  log  includes  the  unique  device 
identifier  as  well  as  synchronized  timestamps  and  device  data  in  a  standardized  nomenclature.  These 
applications  are  engineering  prototypes  intended  for  application  development  and  debugging.  For  the 
UDI  we  used  an  MD  PnP  lab-generated  UDI  as  a  placeholder  for  the  FDA  UDI,  which  for  use  in 
medical  device  interfaces  was  still  under  development. 
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Figure  3.  Logged  Waveform  Data 


©  o  o 


Logged  Data  [ice;:SampleArray] 


Timestamp 

20140212  10:22:28.059 
20140212  10:22:29.083 
20140212  10:22:29.083 
20140212  10:22:29.083 
20140212  10:22:29.083 
20140212  10:22:30.107 
20140212  10:22:30.107 
20140212  10:22:30.107 
20140212  10:22:30.107 
20140212  10:22:31.131 
20140212  10:22:31.131 
20140212  10:22:31.131 
20140212  10:22:31.131 
20140212  10:22:32.155 
20140212  10:22:32.155 
20140212  10:22:32.155 
20140212  10:22:32.155 
20140212  10:22:33.179 
20140212  10:22:33.179 
20140212  10:22:33.179 
20140212  10:22:33.179 
20140212  10:22:34.203 
20140212  10:22:34.203 
20140212  10:22:34.203 
20140212  10:22:34.203 
20140212  10:22:35.227 
20140212  10:22:35.227 
20140212  10:22:35.227 
20140212  10:22:35.227 
20140212  10:22:36.251 
20140212  10:22:36.251 
20140212  10:22:36.251 
20140212  10:22:37.275 
20140212  10:22:37.275 


values 

[1024. 0,1022. 0,1023. 0,1028. 0,1033. 0,1040.0, 1047.0, 1053. 0,1058. 0,1062. 0,1065.0, 1069. 0,1074.C 
[1416.0, 1509.0, 1635. 0,1795. 0,1983.0, 2187.0, 2392.0,2581.0,2743.0,2869.0,2957.0,3011. 0,3037.t 
[1718. 0,1662. 0, 1615. 0, 1579.0, 1554.0, 1540.0, 1537.0, 1544. 0, 1558. 0, 1576. 0, 1595. 0, 1613. 0, 1627. C 
[1140.0, 1123. 0,1108.0,1093.0, 1081.0, 1071.0, 1063.0, 1056.0, 1049.0, 1043. 0,1037.0, 1032. 0,1028.t 
[1140. 0, 1152. 0, 1165. 0, 1178.0, 1189.0, 1201. 0, 1215. 0,1233. 0, 1257.0, 1289. 0,1333. 0,1395.0, 1482. C 
[2629. 0,2544. 0,2455. 0,2366.0, 2278.0, 2 192. 0,2 108.0, 2026. 0,1947.0, 1873. 0,1802. 0,1737.0, 1681. ( 
[1462. 0, 1425. 0,1392. 0,1361. 0,1332. 0,1303. 0,1275. 0,1247.0, 1220. 0, 1194. 0, 1170. 0, 1149. 0, 1132. C 
[1062. 0,1067. 0,1072. 0,1077.0, 1081. 0,1084.0, 1087.0, 1092. 0,1099. 0,1109. 0, 1120. 0, 113 1.0, 1145. t 
[2888. 0,2968. 0,3014. 0,3033. 0,3030.0, 3008.0, 2973. 0,2928.0, 2873. 0,2810. 0,2739. 0,2661. 0,2577.C 
[1570.0, 1590.0, 1609.0,1625. 0,1634.0, 1635.0, 1628.0, 1609.0, 1582.0, 1549.0, 1511. 0,1471. 0,1432. t 
[1042. 0,1038. 0, 1035. 0,1034. 0,1032. 0, 1031. 0,1033. 0,1036. 0,1039. 0,1045. 0,1053. 0, 1061. 0, 1069. C 
[1296. 0, 1341. 0,1405. 0,1494.0, 1613. 0,1766. 0,1948.0, 2 148. 0,2352. 0,2544. 0,2711. 0,2846. 0,2943. t 
[1866. 0,1792. 0,1725. 0,1667. 0,1618.0,1580.0, 1554. 0,1539.0, 1535. 0,1540. 0,1551. 0,1569. 0,1590. C 
[1188. 0, 1167. 0, 1148. 0, 1130.0, 1113. 0,1098.0, 1084. 0,1071. 0, 1061. 0,1053. 0,1046.0, 1040. 0,1036.t 
[1123. 0, 1134. 0, 1144. 0, 1156. 0, 1169.0, 1181. 0, 1191. 0,1202. 0, 1215. 0,1232. 0, 1254. 0,1283.0, 1322. C 
[2802.0,2725.0,2642.0,2555.0,2468.0,2380.0,2294.0,2211.0,2090.0,2011.0, 1935.0, 1790.0,1726.t 
[1391. 0,1358. 0,1327. 0,1299. 0,1273. 0, 1250.0, 1228.0, 1208.0, 1188. 0, 1168. 0, 1148. 0, 1127. 0, 1108. C 
[1085. 0,1087. 0,1087.0, 1087.0, 1088.0, 1089.0, 1094. 0, 1103. 0, 1116. 0,113 1.0, 1147. 0, 1163. 0, 1178. t 
[3012. 0,3038. 0,3042. 0,3026. 0,2994.0, 2949.0, 2894. 0,2830.0, 2757.0, 2677. 0,2594. 0,2509.0,2423. C 
[1608. 0, 1621. 0,1628. 0,1627.0, 1619.0, 1603. 0,1580.0, 1550.0, 15 16. 0,1480. 0,1444. 0,1410.0, 1377.t 
[1038. 0,1037. 0,1038. 0,1040. 0,1043. 0,1046. 0,1049.0, 1053. 0,1056. 0,1058. 0, 1061. 0, 1065. 0,1069.C 
[1380.0, 1461.0, 1573.0,1718.0, 1893.0, 2091.0,2298.0,2496.0,2672.0,2816.0,2922. 0,2991. 0,3029.t 
[1746. 0,1689. 0,1638. 0,1594. 0,1561. 0,1540.0, 1530.0, 1532. 0,1544. 0, 1564. 0, 1588. 0, 1610. 0, 1627. C 
[1156.0, 1133. 0,1113.0,1096.0, 1082. 0,1071.0, 1062.0, 1053.0, 1046.0, 1040.0, 1036.0, 1033.0,1031.t 
[1132. 0,1 143. 0, 1155. 0, 1168.0, 1182. 0, 1197.0, 1212. 0, 1227.0, 1247.0, 1273. 0,1308. 0,1357.0, 1428. C 
[2670.0,2585.0,2498.0,2410.0,2324.0,2239.0,2156.0,2075.0,1996.0,1917.0,1842.0,1771.0,1707.t 
[1473. 0,1437. 0,1404. 0,1372. 0,1341. 0,13 12. 0,1283. 0, 1255. 0,1228. 0,1202. 0, 1178. 0, 1156. 0, 1136. C 
[1064. 0,1066. 0,1067.0, 1069. 0,1072. 0,1076. 0,1082. 0,1090.0, 1100. 0, 1110. 0, 112 1.0, 1134. 0,1146.t 
[2824. 0,2929. 0,2999. 0,3037.0,3049.0, 3039.0, 3012. 0,2970.0, 2916. 0,2852. 0,2780. 0,2702. 0,2618.C 
[1037.0, 1032. 0,1028.0,1026.0,1026.0, 1028.0, 1032.0, 1038.0, 1044.0, 1050.0, 1056.0, 1062. 0,1068.t 
[1277.0,1312.0,1363.0,1437.0,1540.0,1676.0,1844.0,2037.0,2243.0,2446.0,2628.0,2778.0,2892.C 
[1904. 0,1829. 0, 1761. 0,1700. 0,1647.0, 1605. 0,1574. 0, 1553. 0,1542. 0,1540. 0, 1547. 0, 1561. 0,1579.t 
[1208. 0,1 184. 0, 1161. 0, 1141. 0, 1123. 0, 1107.0, 1093. 0,1080.0, 1068. 0,1058. 0,1050.0, 1043. 0,1037.C 
[1106. 0, 1117. 0, 1130. 0, 1143. 0, 1157.0, 1170.0, 1182. 0, 1193. 0,1205. 0,1220. 0,1238. 0,1262.0, 1295. t 


Figure  4.  Data  Samples  with  UDI  and  Time  Stamps 


O  O  UNumertcs 


C  www.openice.info/numerics. html  □  s 


Partition:  change 

UDI 

Metric 

Instance 

Value 

EKQBA2frwckQAQDkyx0bp4iiJyFQJ24QtanK)F 

MDC.RESP_RATE 

0 

@Fri  Aug  29  2014  13:56:12  GMT-0400  (EDT)  {"value”:  12,"device_time": 
{"sec'';1409334972,"nanosec'’:6840000(X)}},@Fri  Aug  29  2014  13:56:14GMT-0400(EDT) 
{”value":12."device.timc";{"sec":1409334974."nanosec":75000000}},@Fri  Aug  29  2014  13:56:15 
GMT-0400  {EDT){’va]ue":12,"device_time":{"sec":I409334975."nanosec”:818000000}},®Fri 

Aug  29  2014  13:56: 17  GMT-0400  (EDT)  {"value":  I2."device  time": 
{"sec":1409334977."nanosec":780000000}},@Fri  Aug  29  2014  13:56:19  GMT-0400  (EDT) 
{"value":12,"device_time":{'sec":1409334979."nanosec':739000000}},@Fri  Aug  29  2014 

13:56:22  GMT-0400  (EDT)  {"value":  12."dcvice_timc": 

{■sec":1409334982,"nanosec":134000000}},@Fri  Aug  29  2014  13:56:24  GMT-0400  (EDT) 
{"value":12,"devicc  timc":{"sec":1409334984,"nanoscc*:13000000}},@Fri  Aug  29  2014  13:56:25 
GMT-0400  (EDT){"value":12."device_time":{"sec":1409334985."nanosec":869000000}}.@Fri 

Aug  29  2014  13:56:27  GMT-0400  (EDT)  {"value":12."device_time": 
{’sec":1409334987."nanosec":893000000}},@Fri  Aug  29  2014  13:56:29  GMT-0400  (EDT) 
{"value":12,"device  time":{"scc":1409334989."nanosec":821000000}},@Fri  Aug  29  2014 

13:56:31  GMT-0400  (EDT)  {"value":12."device  time": 

{"scc":1409334991."naoosec":263000000}},@Fri  Aug  29  2014  13:56:32  GMT-0400  (EDT) 
{"value":12,"device_lime":{"sec":1409334992,"nanosec":805000000}},®Fri  Aug  29  2014 

13:56:34  GMT-0400  (EDT)  {’value":12,"devicc_time": 

{•sec’;1409334994,"nanosec":301000000}},@Fri  Aug  29  2014  13:56:35  GMT-0400  (EDT) 
{"value":12,"device_tinie":{"scc":1409334995."nanoscc":937000000}},@Fri  Aug  29  2014 

13:56:37  GMT-0400  (EDT)  {"value":12,"device_time": 

{"scc":1409334997."nanosec":914000000}} 

®Fri  Aug  29  2014  13:56: 12  GMT-0400  (EDT)  {"value":  1 19."device_time": 
{"sec":0."nanosec":0}}.@Fri  Aug  29  2014  13:56:13  GMT-0400  (EDT) 

{ "value":  1 19,"device_time":{"sec":0,"nanosec":0}},®Fri  Aug  29  2014  13:56:14  GMT-0400 
(EDT)  {"value":119."device_timc":{"sec":0,"nanosec":0}}.@Fri  Aug  29  2014  13:56:15  GMT- 
0400  (EDT)  {"value":  119,"device_timc":{"sec'’:0,"Qanoscc“:0}},@Fii  Aug  29  2014  13:56:16 
GMT-0400  (EDT)  {"value":  119,"devicc_tirac":{"scc'':0.'’nanosec";0}}.@Fri  Aug  29  2014 

13:56:17  GMT-04(X)  (EDT)  { "value":  1 19, "device_time":{"sec":0,"nanosec":0}},®Fri  Aug  29 

2014  13:56:18  GMT-0400  (EDT)  {"value":119.”device_time":{"sec’:0,"nanosec":0}},®Fri  Aug 

29  2014  13:56:19  GMT-0400  (EDT)  ("value":  1 19, "device_time":{"sec":0.'nanosec":0}},®Fri 

Aug  29  2014  13:56:20  GMT-0400  (EDT)  {"value":l  19."device_time': 

("scc’:0.”nanosec":0)).@Fri  Aue  29  2014  13:56:21  GMT.0400  (EDT) 
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Our  continued  work  on  developing  core  OpenICE  infrastructure  included  a  framework  that  allows  for 
data  logging  without  compromising  system  security  or  patient  privacy.  In  collaboration  with  NIST,  we 
performed  research  on  the  best  approach  to  long-term  storage  of  logged  data  that  will  facilitate 
forensic  analysis  of  adverse  events  or  other  events  of  interest.  After  testing  several  strategies  for  data 
logging,  we  identified  that  a  structured  data  archiving  system  is  probably  better  for  archival  of 
complete  patient  data,  and  we  developed  a  prototype  for  storing  OpenICE  streaming  physiological 
data  from  medical  devices  in  MySQL  tables  using  flat  data  files  read  from  the  console  terminal. 

We  conducted  experiments  to  compare  the  performance  of  MySQL  and  other  data  stores  for 
recording  and  searching  data.  This  allowed  us  to  perform  end-to-end  testing  of  the  entire  OpenICE 
system  from  the  equipment  interface  to  the  Data  Logger  as  we  revised  our  OpenICE  platform  (see 
Figures  5-7).  The  OpenICE  lab  data  interface  uses  the  DDS  middleware  employing  IDL  structures  in 
JSON  format  (Figure  5). 


Figure  5.  DDS  Data  Stream 


unique_device_identif ier:  7SpCWvMkvqK25Az7o5gJX4yliDf BvDsnHlxX 

metric_id:  MOC_PRESS_AWAY 

instance_id:  0 

unit_id:  ORAEGER_mbar 

frequency:  125 

values  : 

userData:  5.3,  5.4,  5.4,  5.5,  5.0,  5.3,  5.5,  5.5,  5.5,  5.0,  5.3,  5.0,  5.1,  5.0,  5.2,  5.6,  5.4,  5.1,  5.0,  5.3,  5.0,  4.8,  4.9,  5.3,  5.4 
device_time  : 

sec:  1418167546 
nanosec:  408000000 


unique_device_identif ier :  7SpCWvMkvqk25Az7o5g3X4yllDf 0vDsnHlxX 

metric_id:  MDC_PRESS_AWAY 

instance_id:  0 

unit_id:  DRAEGER_mbar 

frequency:  125 

values  : 

userData;  5.0,  5.0,  4.9,  4.8.  4.9,  5.3,  5.4,  5.0,  5.1,  4,9,  5.4,  5.1,  5.6,  6.0,  6.3,  6.8,  7.2,  7.7,  8.3,  9.0,  9,5,  10,1,  10.7,  11.3,  11 

device_time  : 

sec:  1418187546 
nanosec:  408000000 


unlque_device_identif ier :  7SpCWvMkvqk25Az7o5gJX4yllDf0vDsnHlxX 

metric_id:  MOC_PRESS_AWAY 

instance_id:  0 

unit_id:  DRAEGER_mbar 

frequency:  125 

values  : 

userData:  12.5,  13.1,  13.6,  14.0,  14.6,  15.1,  15.6,  16.2,  16.7,  17.1,  17.4,  17.6,  17.6,  17.6,  17.6,  17.5,  17.4,  17.3,  17.3,  17.3,  17.2, 
17.2.  17.4,  17.4,  17.5 
device_time  : 

sec:  1418187546 
nanosec:  408000000 


unique_device_identif ier:  7SpCWvMkvqk25Az7o5gJX4yllDf0vDsnHlxX 

metric_id:  MOC_PRESS_AWAY 

instance_id:  0 

unit_id:  ORAEGER_mbar 

frequency:  125 

values  : 

userData:  17.6,  17.6,  17.6,  17.6,  17.6,  17.5,  17.5,  17.5,  17.5,  17.6,  17.6,  17.6,  17.7,  17.7,  17.6,  17.6,  17.5,  17.5,  17.5,  17.5,  17.4, 
17.5,  17.5,  17.5,  17.5 
device_time  : 

sec:  1418187546 
nanosec:  408000000 


To  assess  the  feasibility  of  storing  the  data  in  a  MySQL  database,  we  tested  methods  to  capture  the 
data  stream  (for  a  user-specified  number  of  seconds)  from  the  console  terminal  and  write  it  out  to  flat 
text  files.  Those  files  are  then  loaded  into  their  corresponding  MySQL  tables  via  SQL  scripts.  The 
stored  data  can  then  be  displayed  on  a  browser  via  a  PHP  script  that  joins  the  records  in  the  parent 
table  (Figure  6)  with  the  numerical  arrays  stored  in  the  corresponding  child  tables. 


May  2017 


8 


Figure  6.  Parent  SQL  table 


mysql> 

fliysql>  select  *  from  stream; 


rec.id 

1 

date.time 

unique.device.identifier 

1 

metric.id 

instance.id 

unit.id 

frequency  |  dt.sec  | 

dt.nanosec 

1 

1 

1 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2onoev0Jd4ZYx2Fcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  I 

0 

MDC 

DIM 

OIMLESS 

240  1 

d  1 

0 

2 

1 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIHLESS 

240  1 

0  1 

0 

3 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0id4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  11 

0 

MDC 

DIM 

DIMLESS 

240  1 

0  1 

0 

4 

1 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46O4pG 

1 

MDC 

FCG  IFAD  VI 

0 

MDC 

DIM 

DIHLESS 

240  1 

0  1 

0 

5 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG 

1 

MDC 

IMPED  TTMOR 

0 

MDC 

DIM 

OIMLESS 

60  1 

0  1 

0 

6 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  I 

0 

MDC 

DIM 

OIHLESS 

240  1 

9  1 

0 

7 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

PRFSS  HI  D 

1 

MDC 

DIM 

OIMLESS 

120  1 

0  1 

0 

8 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

PULS  OXIM  P 

0 

MDC 

DIM 

DIMLESS 

60  1 

0  1 

0 

9 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  I 

0 

MDC 

DIM 

DIHLESS 

240  1 

0  1 

0 

19 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2orToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  1 

0 

MDC 

DIM 

DIMLESS 

240  1 

0  1 

0 

11 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIMLESS 

240  1 

d  1 

0 

12 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

DIMLESS 

240  1 

d  1 

0 

13 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

DIHLESS 

240  1 

0  1 

0 

14 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIMLESS 

240  1 

d  1 

0 

15 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIMLESS 

240  1 

0  1 

0 

16 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4p6 

MDC 

ECG  LEAD  VI 

0 

HOC 

DIM 

DIHLESS 

240  1 

0  1 

0 

17 

1 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd42YxZFcd6lnW46O4pG 

1 

MDC 

FCG  IFAD  VI 

0 

MDC 

DIM 

OIMLESS 

240  1 

9  1 

0 

18 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG 

1 

MDC 

IMPED  TTHOR 

0 

MDC 

DIM 

OIMLESS 

60  1 

0  1 

0 

19 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

IMPED  TTHOR 

0 

MDC 

DIM 

OIMLESS 

60  1 

9  1 

0 

20 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

PRFSS  HiD 

1 

MDC 

DIM 

DIMLESS 

120  1 

0  1 

0 

21 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

PRESS  BLD 

1 

MDC 

DIM 

OIMLESS 

120  1 

9  1 

0 

22 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6\nW46Q4pG 

MDC 

PULS  OXIM  P 

0 

MDC 

DIM 

OIMLESS 

60  1 

9  1 

0 

23 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG 

MDC 

PULS  OXIM  P 

0 

HOC 

DIM 

OIMLESS 

60  1 

9  1 

0 

24 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  I 

0 

HOC 

DIM 

OIMLESS 

240  1 

9  1 

0 

25 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  I 

0 

HOC 

DIM 

DIMLESS 

240  1 

9  1 

0 

26 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

FCG  IFAD  1 

0 

MDC 

DIM 

DIMLESS 

240  1 

9  1 

0 

27 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  I 

0 

HOC 

DIM 

OIMLESS 

240  1 

9  1 

0 

28 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  I 

0 

MDC 

DIM 

OIMLESS 

240  1 

9  1 

0 

29 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46O4pG 

MDC 

ECG  LEAD  I 

0 

MDC 

DIM 

DIMLESS 

240  1 

9  1 

0 

30 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG 

1 

MDC 

ECG  LEAD  1 

0 

MDC 

DIM 

DIMLESS 

240  1 

9  1 

0 

31 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  I 

0 

MDC 

DIM 

OIHLESS 

240  1 

9  1 

0 

32 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  I 

0 

MDC 

DIM 

OIMLESS 

240  1 

9  1 

0 

33 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  I 

0 

MDC 

DIM 

OIMLESS 

240  1 

9  1 

0 

34 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIHLESS 

240  1 

9  1 

0 

35 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

HOC 

DIM 

OIMLESS 

240  1 

9  I 

0 

36 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG 

1 

MDC 

ECG  LEAD  II 

0 

HOC 

DIM 

OIMLESS 

240  1 

9  1 

0 

37 

1 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIMLESS 

240  1 

9  1 

0 

38 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

HOC 

DIM 

DIMLESS 

240  1 

9  1 

0 

39 

1 

Mon 

Dec 

29 

11 

01:09 

2014 

1 

T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW4604pG 

1 

MDC 

FCG  LEAD  11 

0 

MDC 

DIM 

OIMLESS 

240  1 

9  1 

0 

40 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  II 

0 

HOC 

DIM 

OIMLESS 

240  1 

9  1 

0 

41 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

HOC 

DIM 

OIHLESS 

240  1 

9  1 

0 

42 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

FCG  IFAD  TT 

0 

MDC 

DIM 

DIMLESS 

240  1 

9  1 

0 

43 

1 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

HOC 

DIM 

OIMLESS 

240  1 

9  1 

0 

44 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIHLESS 

240  1 

9  1 

0 

45 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIMLESS 

240  1 

9  1 

0 

46 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

1 

MDC 

ECG  LEAD  II 

0 

MDC 

DIM 

OIMLESS 

240  1 

9  1 

0 

47 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG 

MDC 

ECG  LEAD  II 

0 

HOC 

DIM 

DIMLESS 

240  1 

9  1 

0 

48 

Mon 

Dec 

29 

11 

01:09 

2014 

T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG 

MDC 

ECG  LEAD  II 

0 

HOC 

DIM 

DIMLESS 

240  1 

9  1 

0 

Figure  7.  Stored  data  displayed  in  a  browser 
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m  o  ^ 


100XC3  Wed  Dec  31  10:15  AM  <X  := 


localhost/JoinTablesTestB.php 


C  I 


#00 

i^l  t  I-  I  lA  Al  1^14  +  lo  loeall'os' 

CX3  HI;  PHP  Select .  From  MySQL  Using  MySQI  Joins  Tutorials  -  Oity  .dysscus  Dashboard  Fcatu  .ysseus  Odysseus  Data  S  ..cessing  Logon  -  Dimensions  RM  PHPCraphUb  ing  Library 
rec_td  date_iimc  udi  metric_id  mstance_id  unit_id  freq  sec  nano_sec 

1  Mon  Dec  29  11:01:09  2014  T3Ct2Wyh2oZTocv0jd4ZYxZFcd61nW46Q4pG  MDC_ECG_LEADJ  0  MDC_DIM_DIMLESS  240  0  0 
0247  X)245/)242^)247^.250^.247^.245^.247jO  .250X1 .247 4)^42j0  247  jO  247  X)  242, 0.240, 0245, 0253fl250fl247^^47^.253^.247^.242D.245jO  .250 .247 ^)^5j0 .247 jD253j0253j0 

2  Mon  Dec  29  1 1 :01 :09  2014  T3Ct2Wyh2oZTocv0jd4ZYxZFcd61nW46Q4pG  MDC_ECG_LEAD_U  0  MDC_DIM_DIMLESS  240  0  0 

0237  X)235X)235j0237X).240X)  .240X1 .237X1 .242X1 .245X1 .245X1247 j0253X)258X)253X)  .247  X)247X) 250,0247 X)245X)247X)  .250 X).245X)  .242X1 .245X1 .250X1 .250X1 .250X1 .247 X)247X) 250.0 

3  Mon  Dec  29  1 1:01:09  2014  T3Ct2Wyh2oZTocv0jd4ZYxZFcd61nW46Q4pG  MDC_ECG_LEAD_U  0  MDC_DIM_DIMLESS  240  0  0 

0242X1247 X1247X1245X1.247X)  .250 XI  .255X1 .258X1 258X1 .253X1 .250X1 .245X1 .245X1 .247X1 .250X1 255.0 255,0 250X1247X1.250X1.255X1.250 XI  .247 XI  .250X1 .250 XI  .247X1 .245X1 .247X1 .250 XI  .247X1 

4  Mon  Dec  29  1 1 :0 1 :09  2014  T3CaWyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC_ECG_LEAD_V  1  0  MDC.DIM.DIMLESS  240  0  0 

0242X1247X1250X1.245X1242X1 .242X1 .242X1 .245X1 .245X1 .242X1 .237X1 .237  XI  .242X1 .240 XI  .237  XI  .240 ,0242,0 .240X1237X1.245X1.247X1.245X1 .237 XI  .240X1.245X1 .245X1 .245X1245X1 .250 XI  .245X1 

5  Mon  Dec  29  1 1 :01 :09  2014  T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC_IMPED_TTHOR  0  MDC.DIM.DIMLESS  60  0  0 

-191.000.-190.000,-189.000.-186.000.-I85.000.-182.000,-179.000,-176.000,-172.000,-169.000.-l66.000.-162.000.-159.000.-156.000,-153.000,6Mon  Dec  29  11X)IX)9  2014 
T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG  MDC.ECG.LEAD.1 0  MDC.DIM.DIMLESS  240  0  0 

0330,0235X1335X1330X1323X1305X1 .287 XI  .267 XI 255X1 247 XI 247X1.250 XI  .253X1 .247X1 .247  XI  .255X1 260X1255X1 .247X1245X1.245X1 .245X1 .242X1 .235X1.220X1.203X1 .207 XI  .267 X1378X}il2X) 
7  Mon  Dec  29  11:01:09  2014  T3C2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC.PRESS  BLD  1  MDC.DIM.DIMLESS  120  0  0 

-242.000.-240.000.-238.000.-238.000.-240.000.-244.000.-250.000.-258.000.-266.000,-275.000,-282.000.-288.000.-293.000.-298.000,-303.000.-308.000.-313.000,-315.000,-318.000.-320.00 
8Mon  Dec  29  11:01:09  2014T3Ct2Wyh2oZToevOjd4ZYxZFcd61nW46Q4pGMDC.PULS  OXIM  POMDC  DIM  DIMLESS60  0  0 

808.000,872.000.992.000,1096.000,1200.000,1296.000,1384.000.1448.000.1472.000.1472.000,1448.000.1408.000.1376.000,1328.000.1272.000, 9  Mon  Dec  29  1 1X11X19  2014 
T3Ct2Wyh2oZTocv0jd4ZYxZFcd6lnW46Q4pG  MDC.ECG.LEAD  1 0  MDC.DIM.DIMLESS  240  0  0 

0.265,0.260 .0.260X1.270X)  .280 X1.280X)  .282X1 .292 XI  .300 XI  .307 XI  .307 X13I2X1320X1330X}  .340X1350X1 365X1383,0390X1397X1.403X1397 XI  .390X1383 XI  .378X1 .365  XI  .345X1323 .0300 .0.275,0 

10  Mon  Dec  29  1 1 :01:09  2014  T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG  MDC.ECG.LEAD.1 0  MDC.DIM.DIMLESS  240  0  0 

0.240 .0.237,0337  X1340X1342X)  .242X1 .242X1 .245X1 .247 XI  .245X1 .242X1.245X1 .250 ,0.250,0.247 .0.245,0 .242,0.245X1 347X1347X1.253X1 .253X1 .253X1 .247X1.247 XI  .247 XI  .247 XI  .247X1347 .0.247,0 

1 1  Mon  Dec  29  1 1:01 :09  2014  T3Ct2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG  MDC_ECG_LEAD_I1 0  MDC.DIM.DIMLESS  240  0  0 

0375.0378X1372X1360X1 347X1 .325 XI  .300 XI  .278X1 .260 XI  .245X1 .240 XI  .245X1 .253X1 .250 XI  .247 ,0350,0 355,0 347X1 340X1342X1347 XI  .250 XI  .245X1 .223X1.180X1.1 15X1.095X1.185.0.370X1385,0 

12  Mon  Dec  29  1 1 :01:09  2014  T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC.ECG.LEAD.il  0  MDC.DIM.DIMLESS  240  0  0 

0.270,0373X1375X1382X1392X1.297 XI  .302X1312X1 .323 XI  .328 XI  .332X1 .345X1357  X1360X1372X1397 ,0.420 ,0.435X1.450X1.465X1.475X1.470X1.457X1.448X1.435X1.415X1385  XI 347 XI 305X1373X1 

13  Mon  Dec  29  1 1X11:09  2014  T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC.ECG.LEAD.il  0  MDC.DIM.DIMLESS  240  0  0 

0.235X1335X1335X1337X1340 XI 335X1 .233X1 .237 XI  .245X1 .247 XI  .245X1340 XI  .240X1345X1345X1 342,0342X1345X1350X1350X1353X1 .250 XI  .247 XI  .250 XI  .250 XI  .250X1 .245X1 .242X1 .240X1340,0 

14  Mon  Dec  29  1 1:01:09  2014  T3Cl2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC.ECG.LEAD.Il  0  MDC.DIM.DIMLESS  240  0  0 

0387X1 390X1392X1395X1392X1382X1367X1360 XI 355X1 .250 XI  .247 XI  .247  XI 350X1347X1347 ,0347 .0347 ,0347X1345X1342X1345X1347 XI  .247X1 .230 XI  .203X1.167X1.142X1.158X1317X1 302X1 

15  Mon  Dec  29  1 1X11:09  2014  T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC.ECG.LEAD.U  0  MDC.DIM.DIMLESS  240  0  0 

0355X1360X1360X1360X1360X1360 XI  .265 XI  .267 XI  .270 XI  .273X1375X1 380 XI 385X1 387  XI 387  XI 390 ,0300X1307X1310X1312X1315X1 .315X1 .315X1 .310X1 .307 XI  .302X1 .292,0378X1 .265  XI 355X1 

16  Mon  Dec  29  1 1:01:09  2014  T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC.ECG.LEAD.Vl  0  MDC.DIM.DIMLESS  240  0  0 

0.307  X1312X1312X1305X1 300 XI  .290 XI  .278X1 .265 XI  .255X1 .253X1 .250 XI  .250 XI 350 XI 350 X1347X1345,0345X)345X1345X1345X1347X1347 XI  .245X1 .245X1 .247 XI  .250 XI 358X1378X1 307  XI 347  XI 

17  Mon  Dec  29  1 1:01:09  2014  T3Ct2Wyh2oZToev0jd4ZYxZFcd61nW46Q4pG  MDC.ECG.LEAD.Vl  0  MDC.DIM.DIMLESS  240  0  0 

0.258X1 .258X1360X1360X1363X1 .263X1 .267 XI  .270X1 .273X1 .275X1 .275X1 380 XI 385X1 385X1 387,0 .295X1 .305,0310X1312X)318X1.320 X1.315X1.312X1.310X1.310X1 .305X1 .292 XI 380X1367  XI 355X1 

18  Mon  Dec  29  1 1:01:09  2014  T3C3Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG  MDC.IMPED.TTHOR  0  MDC.DIM.DIMLESS  60  0  0 

-150.000,-146.000,-143.000,-140.000,-137.000,-133.000,-130.000,-126.000,-121.000,-1 17.000,-1 13.000,-108.000,-102.000,-97.000,-91.000, 19  Mon  Dec  29  11X11X19  2014 
T3Cl2Wyh2oZToev0jd4ZYxZFcd6lnW46Q4pG  MDC.IMPED.TTHOR  0  MDC.DIM.DIMLESS  60  0  0 
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In  experimenting  with  data  representation  and  storage  technologies,  we  had  promising  results  with 
MongoDB,  a  new  (initially  released  in  2009)  open-source  database  specialized  for  large  unstructured 
data  sets.  We  streamed  all  data  from  our  lab  network  -  including  all  connected  medical  devices  -  to  a 
MongoDB  database  over  a  month-long  period,  capturing  a  continuous  record  of  data  from  the  devices 
in  the  Lab  during  that  time  (see  Figures  8  and  9):  over  750  GB  of  waveform  data  and  over  200  GB  of 
numeric  data,  as  well  as  36  GB  of  time  synchronization  messages.  We  investigated  how  to  store 
and  compress  this  data,  and  whether  it  would  be  appropriate  for  clinical  uses  to  remove  duplicated  or 
clinically  irrelevant  data  such  as  the  time  synchronization  messages. 

Figure  8.  Screenshot  from  OpenICE.info:  Collections  of  Streamed  Data  Stored  in  MongoDB 


kxialhost  openice 


Restart  required 

You  have  recently  installed  the  bsori_ext  extension  Run  genghisapp  —kiw  then  restart  g«nghisapp  to  use  it 


openice  Collections 


name 

''  documents 

indexes 

size 

AlarmSettings 

6018 

2 

13.6  MB 

ClannpStatus 

5203 

2 

3.9  MB 

DCPSPublication 

0 

2 

24  KB 

DeviceAtertCondition 

442770 

2 

414  MB 

DevceConditionAlert 

0 

2 

24  KB 

DeviceConnectrvity 

12733 

2 

16.7  MB 

Deviceldentity 

443887 

2 

28.3  GB 

GlobaiAlarmSettingsObjecttve 

688 

2 

951.5  KB 

GloDaiSimulationODjective 

963 

2 

1  MB 

HeartBeal 

18943177 

2 

15.6  GB 

InfuskmObjective 

69607 

2 

60.4  MB 

infusionStatus 

4318359 

2 

4  3  GB 

LocalAlarmSettingsObjective 

405 

2 

871.6  KB 

Numeric 

205382875 

2 

219.9  GB 

Patient 

50 

2 

71.9  KB 

PatientAlert 

16711 

2 

18.6  MB 

PatientAssessment 

396156 

2 

543  MB 

PatientDevice 

0 

2 

24  KB 

SampleArray 

377819089 

2 

756.3  GB 

TechnicalAlert 

171305 

2 

192.7  MB 

TimeSync 

33748982 

2 

36.5  GB 

Add  collection 


CJe&gtus,  byjustm  Htleman. 


May  2017 


10 


Figure  9.  Screenshot  from  OpenICE.info:  Example  of  Numeric  Data  Stored  in  MongoDB 
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{topic:"Nuraeric'',partition:("ICiri,doinain:15,key:  i 
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.Id:  I 

topic:  "Muwric*, 
partition:  [ 
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]. 

domain:  15, 
key:  { 

unlque.device.identifier ;  *s]sTvdaHtHtKxep32oyl\«V4hrMAythSS7a'', 
metrie.id:  “nOC.EHO.or.eSEATM" , 

Instance.id:  e, 
unit.id:  "N0C.MM.D1W.ESS* 

}. 

sourcaTimestamp:  ''2«14-»fr-l9Tl»:«l:M.4«42'' 

). 

saiwte;  { 

value:  •. 
device.tiaw;  { 


(topic:"Numeric",partition:("ICU"J,domain;15,key: 

{unique_device_identlfier:"5jgTVdaNtNtKXGp3ZoylleVqhi9bAythBB7e",metric_id:"MDC_PULS_OXIM_SAT_O2",instance_id:0,i 
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-td:  { 

topic:  “Nuearic*, 
partition:  t 
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]. 
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metric.id:  "WC.PULS.0*I".SAT_02”, 
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>. 
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1. 

saapU;  { 
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deviee.tiae:  { 
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nanosec:  4 


1 


> 


{topic:"Nuineric",partition:l’'ICU"l,domaiii:l5,key: 

{umque_device_identifier:"sjgXVdaNtNUCXGp3ZoylleVqhr9bAythBB7e",metricJd:”MDC_CO2_RESP_RAXE",instance_id:0,unit 

09-19X19:01:02.9682"} 


•.Id:  { 

topic:  "Nuaeric", 
partition:  [ 

"jcu" 

]. 

key:  ( 

unique.device.identifier;  *s](TvdaNtHtKX6p32oyl\eV4hr9bAyth6eTe". 
metric.id:  "N0C.C02.RtSP.RATE", 
instanee.id:  4, 

unit. id:  "NOC.oiM^RESP.eeR.MiN" 

>. 

SOurceTimestaap:  ’24t4-99-ieT14:41:42.949Z* 

i, 

sample;  { 

value:  14, 
device.time:  { 

sec:  14111499S2, 
nanosee:  4 

> 

1 


{topic:"Numeric",partition:C"ICU"),domain:15,key: 

{uiilque_devlceJdentifier:"s)gXVdaNtNtKXGp3ZoylleVqhr9bAythBB7e".metricJd:"MDC_PULS_OXIM_PULS_RAXE".instanceJ. 

09-19X19:01:02.9702"} 


•  -id:  t 

topic:  "Muaeric*. 
partition;  [ 

"ICIT 

], 

domain;  15, 
key:  { 

unique.device.identifier:  "sliTVdaNtMtKXGpSZoylleVqhrRbAythMTe". 

metric.id:  "noc_puls_oxin_puis_rate", 
instanee.id:  4, 

unit. id:  "NOC.PlN.REAT.feR.NIN" 

}. 

SOurceTimestamp:  ’2414-99-19T19:t}:42.979Z’ 

], 

sample:  { 

value:  :i, 
devire.rime-  t 

sec:  1411149452, 
nanosee:  4 


> 
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Our  latest  OpenICE  app  features  data  capture,  storage  and  export  functionalities.  We  have  enabled 
multi-patient-multi-device  assignment,  and  the  data  generated  from  these  devices  can  be  logged  to  a 
variety  of  data  formats  (see  https://www.openice.info/docs/3  apps.html#data-recorder). 

•  CSV  -  This  document  will  save  as  a  comma-separated  values  (csv)  file,  which  may  be  imported 
by  most  data  analysis  programs,  including  Microsoft  Excel 

•  sql  -  Structured  Query  Language  storage  format  -  used  in  many  common  databases  including 
Microsoft  Access 

•  vcd  (IEEE-1364)  -  Value  Change  Dump  -  a  waveform  storage  format  defined  by  the  Institute 
of  Electrical  and  Electronics  Engineers  (IEEE)  in  the  IEEE  Standard-1364-1995  in  1995 

Figure  10.  Data  Recorder  reading  data  feeds  from  multiple  devices 
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For  HIMSS2015  we  created  and  demonstrated  an  HL7  FHIR-compliant  data  export  feed  which  can 
selectively  send  data  points  by  patient  at  an  adjustable  frequency  (see  Aim  3  below). 

Figure  11.  HL7  FHIR  format  data  export  capabilities 
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Having  demonstrated  storing  streaming  device  data  from  the  OpeniCE  interface  to  MySQL  tabies 
using  fiat  data  fiies  read  from  the  consoie  terminai  with  a  Peri  script,  we  next  configured  the  Odysseus 
Studio  Data  Base  Management  System  using  a  research  tooi  from  the  University  of  Oidenburg 
(Germany)  that  provides  a  data  handier  for  DDS  interfaces,  to  accompiish  this  directiy  by  intercepting 
the  data  stream  and  importing  it  into  MySQL  tabies. 

We  created  a  short  demo  screen  recording  showing  the  database  storage  of  the  puise  oximeter  data 
stream  using  the  simuiator  in  the  MD  PnP  Demo  Apps.  Two  tabies  are  automaticaiiy  created  -  one 
storing  the  records  with  the  waveform  data  and  the  other  storing  the  remaining  records.  We  upioaded 
the  video  to  the  QneDrive  website,  to  make  it  avaiiabie  for  viewing.  Whiie  this  sharing  site  is  no  ionger 
avaiiabie,  screen  shots  are  shown  in  Figures  12  and  13  beiow. 

Figure  12.  Screenshot  of  Qdysseus  Studio  2  demo  video  on  QneDrive  website 
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Figure  13.  Screenshot  of  tables  of  waveform  data  in  Odysseus  Studio  2  database  storage  platform 


«-  C  a  Microsoft  Cofpoiation  [US]]  https://onedrive.live.com/?cid=024E876FC91BFlDl&id=24E876FC91BFlDl%21107&v=3  1  = 


Once  we  moved  the  prototype  data  logger  to  our  DDS-based  open  source  implementation,  we 
performed  extensive  end-to-end  performance  testing  to  ensure  that  the  entire  system  could  handle 
large  amounts  of  data.  It  was  important  for  us  to  assess  the  maximum  data  throughput  of  the  system. 
We  found  that  the  data  logging  rate  was  primarily  dependent  on  storage  hardware,  not  the  ICE  data 
acquisition  or  integration  software.  These  results  will  allow  us  to  specify  the  storage  requirements  for 
individual  ICE  data  loggers  and  also  for  an  architecture  where  all  ICE  data  is  backed  up  in  a  central 
data  store  at  the  Healthcare  Delivery  Organization.  These  findings  have  been  valuable  for  the  framing 
of  the  ICE  Data  Logger  standard. 

The  NIST  team  visited  our  Lab  in  March  2014  as  part  of  a  three-day  SmartAmerica  “hackathon”  (see 
http://smartamerica.orq/teams/closed-loop-healthcare/  and  http://mdpnp.orq/smartamerica.php).  and 
we  collaborated  to  connect  their  prototype  to  our  OpenICE  platform  to  collect  data.  Based  on  the 
research  results  to  date,  NIST  re-worked  their  prototype  data  logger  to  work  with  DDS,  and 
demonstrated  it  at  the  SmartAmerica  Expo  in  June  2014  (as  part  of  the  Closed  Loop  Healthcare 
team),  including  a  demonstration  of  the  data  logging  and  analysis  system  based  on  OpenICE  running 
on  a  PC  as  well  as  an  iPad  interfaced  to  that  system.  NIST  subsequently  posted  their  data  logger 
source  code  to  an  online  repository. 

Once  the  FDA  Unique  Device  Identifier  (UDI)  ruling  was  published  in  September  2013,  we  explored 
how  to  use  the  data  format  and  content  identified  in  the  ruling  within  our  OpenICE  implementation. 
The  UDI  ruling  lists  information  intended  for  printing  on  the  packaging  of  medical  devices  and 
transmission  by  AIDC  (Automated  Identification  and  Data  Capture)  technologies  such  as  bar  codes 
and  RFID,  but  not  UDI  transmitted  over  Electronic  Data  Interfaces  (i.e.  network  connections).  Dr. 
Goldman  was  part  of  a  group  convened  by  the  FDA  and  Brookings  Institute  to  promote  adoption  of 
UDI  in  registries  and  administrative  health  care  claims.  As  part  of  the  UDI  Implementation  Work 
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Group,  he  participated  in  discussions  with  FDA  and  Brookings  about  prototyping  electronic 
communication  of  UDIs  and  the  role  of  UDI  in  interoperable  systems,  and  our  team  worked  to 
determine  how  to  extend  our  current  UDI  implementation  with  additional  information  from  the  ruling. 
This  was  expected  to  enhance  data  logging  and  playback  with  additional  information  about  the  device 
manufacturer,  manufacturing  date,  batch  ID,  and  so  on. 

Beginning  in  2014  we  focused  much  of  our  Data  Logger  effort  on  preparing  a  draft  standard  for  the 
ICE  Data  Logger:  Medical  devices  and  medical  systems  —  Basic  safety  and  essential  performance  of 
the  patient-centric  integrated  clinical  network  environment  (ICE):  Particular  requirements  for  the 
forensic  data  logger.  We  decided  that  taking  time  to  write  the  draft  standard  would  be  valuable  in 
identifying  further  requirements  before  the  next  round  of  development. 

As  part  of  the  drafting  of  this  standard,  we  extensively  reviewed  literature  and  standards  associated 
with  data  loggers  covering  different  modes  of  transportation,  publications  describing  clinical  data 
loggers,  and  earlier  work  on  clinical  requirements  done  by  the  MD  PnP  Program  to  highlight  the 
specific  needs  of  clinical  data  logging.  In  addition,  FDA  guidance  and  other  documents  (e.g.  event 
codes,  UDI  guidance,  medical  device  reporting  regulations)  and  other  ISO  standards  (e.g.  clinical 
evaluations)  were  consulted  and  cited  to  ensure  consistency  of  the  requirements  in  the  draft  standard 
with  these  documents. 

In  order  to  provide  additional  supporting  rationale  for  the  draft  standard,  we  explored  the  modification 
and  inclusion  of  requirements  related  to  patient  privacy  and  data  security.  Our  continuing  participation 
in  related  standards  activities  -  including  ISO  TO  121,  IEEE  11073  POC/PHD,  AAMI  Interoperability 
Working  Group,  and  the  Joint  AAMI/UL  2800  -  has  helped  ensure  harmonization  with  other  standards 
work. 

In  May  2014  Dr.  Goldman  and  a  consultant,  Michael  Jaffe,  presented  the  draft  Data  Logger  standard 
to  the  team  at  NIST  for  feedback  that  was  then  incorporated  into  the  draft.  We  circulated  the  draft  to 
additional  collaborators  for  review,  and  then  to  a  broader  group  of  domain  experts.  Much  of  this  initial 
feedback  was  incorporated.  Further  iterations  of  the  draft  enhanced  its  suitability  for  submission  into 
the  standards  development  process  as  a  new  work  item  proposal  (NWIP).  The  resulting  ICE  Data 
Logger  proposed  draft  standard  is  attached  to  this  report. 

From  2014-2016,  data  logging  capabilities  were  demonstrated  in  our  MD  PnP  Lab  in  Cambridge,  MA, 
to  many  medical  device  and  software  companies,  computer  scientists,  clinicians,  and  standards 
developers.  The  insights  obtained  from  our  research  were  shared  in  those  meetings  and  in  public 
presentations,  and  feedback  was  used  to  refine  the  project.  We  added  new  capabilities  and  features 
to  the  OpenICE  Data  Recorder,  including  tracking  of  patient  IDs,  additional  numeric  vital  signs,  the 
ability  to  select  data  elements  for  recording  by  device  or  individually,  and  the  ability  to  export  data  to 
MongoDB.  The  ICE  data  logging  research  capability  was  incorporated  into  the  publicly  available 
OpenICE  software. 

Clinical  Scenario  Repository,  Aim  2:  Develop  a  sharable  repository  of  clinical  scenarios  that  could 
be  improved  through  better  medical  device  and  health  IT  integration. 

Based  on  foundational  research  performed  in  our  program  and  presented  at  a  Scientific  and 
Educational  Exhibit  at  the  2006  American  Society  of  Anesthesiologists  Annual  Meeting 
(http://mdpnp.orq/uploads/MDPnP  Booklet  February  2007  p1-21.pdf),  we  developed  a  system- 
engineering-based  model  for  the  medical  device  interoperability  ecosphere.  Inputs  to  the  system 
needed  to  begin  with  "Clinical  Scenarios"  -  use  cases  from  a  clinical  perspective  that  describe  the 
clinical/functional  capabilities  of  the  interoperable  system  that  can  support  innovative  workflows  in 
support  of  patient  safety  improvements. 


May  2017 


15 


As  a  result  of  earlier  work  on  clinical  requirements  for  medical  device  interoperability,  the  MD  PnP 
team  had  built  a  prototype  clinical  scenario  database  as  a  student  project  during  summer  201 1 ,  under 
funding  from  TATRC  award  W81XWH-09-1-0705.  This  database  included  a  web-based  user 
interface,  a  database  back-end,  and  an  administrative  system  to  organize  users  and  permissions,  and 
collaborators  at  the  FDA  and  NIST  provided  useful  feedback.  Based  on  this  pilot  work,  we  committed 
to  build  a  scalable  and  user-friendly  system  under  this  new  award  (W81XWH-12-C-0154),  beta-tested 
by  our  collaborators  and  refined  via  focus  group  input,  then  released  to  a  broader  audience. 

Objectives  for  the  first  year  included  building  and  testing  a  robust  preliminary  web-based  prototype  of 
the  Clinical  Scenario  Repository™  (CSR™),  leveraging  earlier  work  done  under  award  W81XWH-09- 
1-0705.  We  invested  substantial  effort  in  a  careful  design  and  implementation  that  facilitated  both 
administration  and  general  usability  of  the  Clinical  Scenario  Repository. 

The  clinical  scenario  repository  web  application  was  totally  rebuilt  from  the  original  prototype,  with 
numerous  additions  to  functionality  that  were  more  efficiently  implemented  using  newer  frameworks. 
We  used  a  common  toolkit  for  building  the  site  that  gave  it  modern  features,  e.g.  data  saved 
automatically  as  a  draft  in  progress  while  the  user  is  working,  with  the  option  to  manually  “Save  for 
later”,  and  at  the  end  of  data  entry,  the  user  given  the  option  to  “Submit  for  approval.” 

The  prototype  Clinical  Scenario  Repository  was  based  on  the  template  designed  by  the  MD  PnP 
research  team  for  describing  and  documenting  information  related  to  clinical  scenarios  and  use  cases 
that  could  benefit  from  medical  device  interoperability.  The  application  requests  information  from  the 
user  followed  an  easy  and  descriptive  approach  utilizing  a  series  of  tabs: 

•  Scenario  Description:  is  where  the  user  can  describe  in  detail  the  adverse  event  or  clinical 
challenge  -  the  current  state.  They  can  also  describe  the  enhancement  in  safety  that  can  be 
accomplished  by  an  integrated  solution  in  a  proposed  state. 

•  Hazards:  is  used  to  describe  the  factors  contributing  to  the  risk  represented  by  the  scenario, 
including  their  level  of  severity  and  the  expectation  of  occurrence. 

•  Environments:  is  used  to  capture  the  clinicians  involved  in  the  scenario  (e.g.  nurse, 
anesthesiologist,  surgeon,  etc.)  and  the  environment  where  it  took  place  (e.g.  operating  room, 
hospital  ward,  ambulance,  etc.). 

•  Equipment:  is  used  to  describe  the  medical  devices  or  sensors  that  play  an  important  role  in 
the  scenario. 

•  Proposed  Soiution:  allows  for  a  more  extensive  description  of  an  ideal  state  or  workflow,  and 
how  it  might  affect  or  change  the  practice  environment. 

•  Benefits  and  Risks:  is  used  to  gather  information  about  the  obstacles  eliminated  by  the  new 
process,  as  well  as  any  new  risks  that  might  be  introduced  by  the  proposed  solution,  so  these 
can  be  mitigated  in  advance. 

•  Feedback:  available  only  to  administrators  reviewing  a  submitted  scenario,  this  tab  is  used  to 
approve  the  scenario  (granting  any  registered  user  permission  to  see  it)  or  to  request 
clarification  from  the  scenario  submitter  via  email. 

An  alpha  version  of  the  prototype  CSR™  was  demonstrated  in  August  2013  to  USAMRMC/TATRC 
and  other  federal  agencies  (see  below).  That  CSR™  had  user  features  to  create  new  scenarios  and 
search  the  existing  database  of  scenarios,  and  system  administrator  features  to  review,  approve,  and 
manage  scenarios.  It  was  hosted  on  the  Google  Application  Engine,  which  provided  an  easy  and 
reliable  way  of  managing  the  user  log-in  process,  email  communications,  and  data  storage,  and 
enabled  our  developers  to  use  the  web  development  technologies  necessary  to  implement  the 
browser  side  of  the  web  portal.  Features  included  a  user  registration  and  log-in  process,  as  well  as 
the  persistence  of  administrative  user  information,  the  data  from  the  scenario  description,  and  other 
related  data  (such  as  keywords  to  tag  the  scenarios  for  search/indexation  purposes). 


May  2017 


16 


Our  implementation  included  a  database  schema  that  is  a  superset  oi  the  data  specified  in  the  clinical 
scenario  template  of  Annex  B  of  ASTM  standard  F2761-09(13)  for  the  Integrated  Clinical  Environment 
(ICE).  We  normalized  the  schema  to  make  it  robust  enough  for  the  higher  traffic  anticipated  on  a 
generally  available  web  site.  We  formally  defined  the  state  model  for  a  scenario  (e.g.  In  Progress, 
Pending  Approval,  Approved,  etc.),  which  was  a  challenging  task  because  the  rules  for  transitioning 
from  one  state  to  another  -  or  even  the  number  of  states  -  might  change  as  we  develop  new  features, 
receive  feedback  from  our  collaborators,  and  consider  different  behaviors  in  the  users’  interaction  with 
the  application. 

Basic  user  roles  were  defined  (unregistered  visitor,  registered  collaborator,  and  system  administrator), 
and  a  coherent  set  of  functionalities  and  privileges  was  granted  to  each  role.  For  example,  system 
administrators  can  view  all  scenarios  submitted,  registered  collaborators  are  able  to  view  all  approved 
scenarios  as  well  as  scenarios  they  have  themselves  entered,  regardless  of  status,  and  unregistered 
visitors  can  view  only  scenarios  that  have  been  approved  and  are  part  of  the  viewable  database  - 
they  cannot  enter  a  scenario  unless  they  register.  We  added  the  “unregistered  visitor”  role  as  a  way  to 
show  some  utility  to  a  new  visitor  and  provide  them  a  motivation  to  register  with  our  site. 

Major  features: 

•  Registration:  The  Google  Application  Engine  provided  a  registration  system  for  users  using 
Google  IDs.  This  relieved  us  from  implementing  our  own  registration  system  and  requesting, 
encrypting  and  securely  managing  and  maintaining  usernames,  passwords  and  other  personal 
information  from  users;  this  allowed  us  to  focus  on  the  features  at  the  heart  of  the  repository. 
This  registration  process  was  extended  to  include  “OpenID  federated  login”  and  other  existing 
providers  for  Secure-Socket-Layer  authentication  and  registration.  The  personal  information 
shared  in  the  registration  process  is  kept  private  and  is  not  shared  with  other  users. 

•  Scenario  Entry:  For  scenario  entry  our  design  follows  a  tabbed  “breadcrumb”  approach, 
allowing  the  user  to  move  easily  between  sections  of  the  scenario  entry  process  without 
enforcing  a  strict  path  through  those  sections.  This  allows  Registered  Users  to  immediately 
enter  the  information  they  have  readily  available,  and  to  easily  return  later  to  complete  other 
sections.  At  the  top  of  each  text  entry  box,  we  include  pop-up  menus  to  provide  an  "example 
scenario"  to  show  what  to  fill  in.  The  clear  explanation  of  fields  will  help  users  to  enter  more 
useful  data,  and  is  an  example  of  using  user  feedback  to  identify  additional  ways  to  provide 
contextual  assistance. 

•  Search:  Our  search  functionality  follows  a  “keyword”  approach,  offering  the  user  the  ability  to 
search  all  data  fields  for  keywords  of  interest. 

•  Approval  Workflow:  Our  Repository  Administrator  is  able  to  view  new  pending  scenarios 
submitted  by  Registered  Users,  and  will  review  and  approve  scenarios  before  they  become 
part  of  the  public  repository.  In  anticipation  that  content  clarification  will  be  needed  for  many 
submissions  prior  to  public  sharing,  we  have  facilitated  communication  between  submitters 
and  approvers  using  an  email  feature. 

Traditionally  web  apps  have  followed  a  simple  “form  submission”  model  where  a  user  fills  out 
numerous  fields  and  clicks  Submit  We  used  a  more  modern  approach  (AJAX  mechanism)  that  allows 
us  to  save  a  user’s  progress  while  they  are  working  in  order  to  ensure  no  data  is  lost.  This  introduced 
new  challenges  -  for  instance,  we  must  store  and  manage  all  of  a  user’s  current  draft  work.  We  also 
had  to  make  decisions  about  how  often  and  with  what  granularity  to  send  data  back  to  the  server. 

For  the  storage  of  data,  using  Google  App  Engine  presented  new  decisions.  One  option  was  to  use  a 
more  traditional  Relational  Database  Management  System  (RDBMS)  hosted  either  in  the  cloud  or  on 
our  own  servers.  A  second  option  was  to  use  the  Google  High  Replication  Datastore,  a  “big  data” 
technology  that  scales  far  better  than  an  RDBMS  but  creates  other  issues.  We  initially  stayed  within 
the  confines  of  an  abstraction  layer  (“Java  Data  Objects”)  that  supports  either  storage  subsystem. 
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Users  can  save  the  scenario  information  at  any  time,  allowing  them  to  enter  the  information  available 
at  the  moment  and  to  revisit  these  tabs  at  another  time  to  complete  or  update  the  information.  This 
approach  relieves  the  user  of  being  forced  through  a  multitude  of  input  fields  and  constrained  data 
input  workflow  processes.  We  received  positive  feedback  on  the  intuitive  navigation  from  NIH  demo 
attendees. 

During  the  first  year  of  this  award,  we  leveraged  the  work  performed  under  award  W81XWH-09-1- 
0705  to  build  and  test  a  robust  preliminary  web-based  prototype  of  the  Clinical  Scenario  Repository 
(CSR™).  An  alpha  version  prototype  was  developed,  tested  and  shared  among  internal  collaborators, 
who  provided  valuable  feedback.  The  culmination  of  our  first  year’s  work  was  the  opportunity  to  show 
the  alpha  version  of  the  prototype  Clinical  Scenario  Repository  when  we  presented  a  series  of 
demonstrations  of  our  work  at  NIH  on  August  21-22  2013  for  invited  representatives  from  federal 
agencies.  There  were  over  60  attendees  from  DoD,  FDA,  NIST,  NIH,  and  other  federal  agencies,  and 
we  received  positive  feedback,  encouraging  us  to  develop  additional  features,  e.g.  advanced  search 
capabilities  that  might  include  an  ontology  of  terms  and  use  of  natural  language  processing  of 
submitted  text  to  auto-create  keyword  tags.  Subsequently,  the  prototype  repository  was  presented 
several  times  as  part  of  our  Lab  Open  House  tours  in  September  2013  and  other  demonstrations  of 
our  work  to  visitors  and  collaborators. 

In  preparation  for  the  initial  beta  test,  the  functionality  of  the  CSR™  was  greatly  enhanced.  While 
some  of  these  features  reflected  needs  we  had  already  identified  internally,  many  of  them  were  the 
direct  result  of  the  feedback  from  federal  attendees  at  the  August  technology  demonstrations.  We 
were  careful  to  implement  the  requested  features  in  a  way  that  protects  health  information,  while  also 
responding  to  user  expectations  regarding  usage  and  functionality.  One  challenge  that  surfaced  in  the 
August  demos  was  related  to  a  suggestion  that  repository  users  be  able  to  annotate  existing 
scenarios  and  increment  the  information  contained  within  scenarios  -  this  kind  of  feature  raised 
issues  about  governance  of  the  data  contained  in  the  repository,  and  underscored  the  need  for  a 
process  that  enforces  our  policy  of  not  including  any  personal  or  defamatory  information  in  the 
scenarios. 

The  beta  version  of  the  CSR™  was  released  in  December  2013  to  a  pilot  group  of  internal  MGH 
users,  has  been  shown  to  several  groups  visiting  the  MD  PnP  Interoperability  Lab  (including 
standards  development  committees  and  industry),  and  was  shown  publicly  to  clinicians  and  engineers 
at  the  annual  meeting  of  the  Society  for  Technology  in  Anesthesia  (STA)  in  January  2014.  The  CSR™ 
had  considerable  exposure  at  STA  -  it  was  one  of  the  hands-on  stations  in  our  two-hour  OpenICE 
workshop,  and  was  presented  in  a  lecture  and  poster.  The  CSR™  had  also  been  presented  in  a  panel 
with  Johns  Hopkins  and  Mayo  Clinic  at  the  Society  for  Critical  Care  Medicine  meeting  in  San 
Francisco  the  week  prior  to  STA. 

We  received  many  new  ideas  and  requests,  as  well  as  feedback,  from  STA.  Both  clinical  and  industry 
users  expressed  concern  about  information  that  the  CSR™  could  make  available  to  the  general  public 
on  specific  medical  device  models  and  products,  e.g.  possible  malfunctioning,  less  competitive  array 
of  functionality  and  features,  general  problems,  etc.  While  some  manufacturer  representatives 
expressed  interest  in  using  the  content  of  the  repository  as  feedback  to  verify  product  functionality  and 
address  new  features  or  product  opportunities,  they  also  proposed  restricting  access  to  the  CSR™ 
content  to  the  QA  departments  of  hospitals  and  companies.  This  confirmed  our  own  concerns  about 
the  extent  of  governance  issues  to  be  addressed,  and  about  taking  additional  cautionary  measures 
with  the  scenario  approval  workflow. 

While  we  had  anticipated  the  need  for  an  approval  process  that  could  validate  the  content  of  CSR™ 
submissions  before  making  the  scenarios  available  to  all  users,  additional  aspects  of  the  governance 
process  surfaced.  For  example,  STA  attendees  (clinicians  and  manufacturers)  emphasized  that  even 
if  a  scenario  does  not  contain  specific  defamatory  information  (names  of  doctors,  hospitals,  etc.),  that 
is  not  enough  to  guarantee  the  absence  of  defamatory  information  -  the  CSR™  should  not  have  any 
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kind  of  implicit  defamatory  information  that  could  be  derived  from  the  content  posted.  Moreover,  we 
had  to  reevaluate  the  consequences  of  opening  a  tool  like  the  CSR™  to  the  general  public  -  while  it 
was  our  intent  that  this  repository  not  substitute  for  other  mandatory  reporting  systems  (required  for 
medico-legal  and/or  regulatory  purposes),  there  could  be  submissions  that  would  require  CSR™ 
administrators  to  act  upon  receiving  them,  e.g.  mention  of  abuse  or  other  such  reportable  events.  This 
underscored  the  importance  of  having  a  well-thought-out  governance  approach  and  process. 

We  examined  how  clinical  scenarios  in  the  CSR™  could  be  cross-referenced  with  other  databases 
and  with  our  other  project  work,  e.g.  linking  to  further  documentation  of  ConOps  (engineering  Concept 
of  Operations)  or  requirements.  In  the  future,  the  CSR™  could  be  expanded  to  include  the  other 
artifacts  that  are  necessary  to  follow  a  scenario  all  the  way  to  implementation. 

An  important  milestone  accomplished  during  in  the  second  year  was  successfully  deploying  the 
CSR™  web  application  on  our  own  managed  servers,  moving  away  from  the  Google  Application 
Engine  that  was  used  in  the  prototype’s  early  stages. 

Ensuring  adequate  authentication  and  authorization  mechanisms  was  one  of  the  CSR™  priorities. 
Several  promising  technologies  were  considered  for  this  task,  including  Spring  Security,  a  powerful 
and  highly  customizable  authentication  and  access  control  framework,  and  BCrypt,  the  Java 
implementation  of  a  hashing  algorithm  that  would  allow  for  hashing  a  password  (ensuring  that  users’ 
passwords  and  other  sensitive  data  are  not  stored  using  plain  text  in  the  database)  and  SSL 
certificates.  We  also  focused  on  obtaining  the  appropriate  authentication  and  authorization 
mechanisms  needed  for  the  governance  process. 

The  unique  attributes  of  this  CSR™  -  i.e.  not  linked  to  a  single  medical  device  failure  (in  contrast  to 
the  FDA  MAUDE  database),  not  required  to  have  a  1:1  relationship  between  a  scenario  event/idea 
and  submission  (like  hospital  adverse  event  reporting),  not  linked  to  a  specific  patient  (or  any  patient), 
free  text  entry,  etc.  -  opens  the  door  for  a  new  approach  to  healthcare  quality  improvement.  Even  with 
the  limited  release  possible  within  this  project,  the  CSR™  generated  excitement  and  the  contribution 
of  ideas  by  leaders  from  industry,  patient  safety,  and  clinical  domains.  We  envision  even  more  interest 
if  an  improved  CSR™  is  publicly  released.  Moreover,  we  expect  a  linkage  will  develop  between  this 
work  and  the  Federal  initiatives  around  device/HIT  safety,  as  well  as  patient  safety  societies  and 
patient  networks. 

The  Clinical  Scenario  Repository  (CSR™)  was  presented  at  the  Military  Health  System  Research 
Symposium  (MHSRS)  in  August  2014  in  Fort  Lauderdale,  FL,  where  it  received  enthusiastic  praise 
from  DoD  representatives  excited  about  the  idea  of  having  a  tool  that  would  allow  capturing  “good 
ideas”.  They  felt  the  CSR™  differentiated  itself  from  other  such  systems,  first,  by  eliminating  the 
negative  connotations  of  reporting  mechanisms  and  tools  (e.g.  being  perceived  as  tedious  and  time- 
consuming  processes  with  potential  negative  repercussions  for  the  reporter),  and  second,  by 
encouraging  users  to  share  their  own  expertise  and  ideas,  with  the  potential  to  improve  many  different 
aspects  of  the  healthcare  landscape.  The  scenario  submission  workflow  had  been  simplified  such  that 
the  limited  mandatory  information  is  provided  via  a  description  of  the  event  in  plain  language  and  a 
title  that  summarizes  the  scenario  in  a  way  that  easily  identifies  it. 

The  feedback  provided  by  DoD  encouraged  us  to  incorporate  the  term  “good  ideas  for  patient  safetf 
in  the  mission  definition  of  the  CSR™,  to  better  explain  that  this  tool  is  not  only  intended  to  point  out 
technology  gaps  and  raise  awareness  about  events  that  would  not  otherwise  be  reported,  but  also 
allows  sharing  ideas  and  experience  to  improve  these  perceived  gaps  or  patient  care  in  general. 

The  CSR™  was  also  presented  during  the  open  house  sessions  for  the  Medical  Device  Plug  and  Play 
program’s  10'*^  anniversary  in  October  2014.  Visitors  stressed  that  the  main  difficulty  in  reconstructing 
and  analyzing  adverse  events  is  having  available  the  necessary  information  about  the  event;  this 
aligns  with  our  attempt  to  keep  the  submission  process  simple  while  capturing  as  much  detail  as 
users  are  willing  to  offer. 
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The  primary  functionality  of  the  CSR™,  capturing  a  clinical  event  or  idea,  was  completed  during  this 
project.  Users  can  develop  a  clinical  scenario  through  a  workflow  that  allows  them  to  submit  the  basic 
information  in  plain  language  and  expand  it  further  to  incorporate  advanced  technical  details.  While 
currently,  for  the  sake  of  simplicity,  each  event  has  only  a  single  solution,  it  should  be  possible  to 
modify  the  CSR™  so  that  users  can  propose  multiple  solutions  to  the  same  event,  in  order  to 
compare,  discuss  and  evaluate  different  approaches  to  a  problem  affecting  patient  safety. 

During  2015  and  2016  the  CSR™  was  shared  with  the  Committee  on  Patient  Safety  and  Quality  of 
the  American  Society  of  Anesthesiologists  (ASA),  the  AHRQ  Patient  Safety  Organization  (PSO) 
experts,  the  CRICO  risk  management  foundation  (https://www.rmf.harvard.edu/),  and  ISO  TC  121,  to 
optimize  the  user  interface  and  help  identify  a  pathway  to  obtain  broad  input  into  the  CSR™.  We 
made  the  CSR™  available  to  select  groups  by  deploying  the  application  in  our  own  managed  servers 
at  https://csr.openice.info/.  so  that  both  the  application  and  the  data  collected  are  easily  managed  and 
kept  safe.  The  advice  provided  by  these  representatives  highlighted  the  need  to  improve  the  data 
collection  mechanism  based  on  the  feedback  provided  by  users  of  the  repository.  Meetings  with 
AHRQ,  CRICO,  and  MGH  were  also  part  of  our  discussions  of  governance  and  application  areas. 

In  order  to  maximize  the  leverage  provided  by  the  feedback  for  this  project  from  these  users  of  the 
CSR™,  we  continually  updated  the  prototypes  with  new  features  motivated  by  the  users’  comments, 
ideas  and  needs  for  this  project.  Internal  users  tested  these  features  before  they  were  approved  and 
deployed  on  the  prototypes  we  shared  on  the  worldwide  web.  The  representatives  from  the  CRICO, 
ASA,  and  AHRQ  praised  the  idea  of  allowing  users  to  describe  events  or  ideas  in  plain  language.  This 
process  contributed  greatly  to  the  refinement  and  evolution  of  the  Clinical  Scenario  Repository™. 

Based  on  research  and  feedback,  we  migrated  the  CSR™  to  a  different  (third)  platform,  largely  due  to 
the  unsuitability  for  reliable  long-term  data  storage  and  easy  user  ID  authentication  provided  by  the 
Google  technologies  chosen  to  develop  the  early  prototypes.  Migrating  from  MySQL  to  a  Mongo 
database  proved  a  good  match  for  the  technical  needs  of  the  CSR™.  One  of  the  key  challenges  of 
this  application  was  to  offer  simple  yet  detail-rich  interfaces  to  enable  users  to  provide  as  much  (or  as 
little)  information  as  they  wish  or  as  they  have  available  at  the  moment.  This  forces  the  data  model  to 
change  frequently  when  new  fields  are  suggested  or  requested  by  users.  Mongo  databases  are  ideal 
for  unstable  schemas,  since  adding  a  new  field  (for  example,  information  related  to  the  drugs  involved 
in  a  scenario,  such  as  name  of  the  drug,  dosage,  etc.)  won’t  affect  existing  rows  or  documents.  This 
proved  an  advantage  for  both  development  and  deployment  of  newer  versions  of  the  application, 
requiring  less  effort  from  database  administrators. 

In  addition,  an  implementation  using  JavaScript,  HTML  and  Mongo  proved  faster  and  more  efficient 
when  persisting  and  retrieving  data  than  the  former  implementation  using  the  Google  Web  toolkit  and 
a  MySQL  database.  We  implemented  a  quick  and  easy  way  of  creating  user  accounts  that  provides 
the  option  of  using  OAuth  services,  e.g.  using  the  user’s  Google  account  to  sign  in  to  the  CSR™. 
When  creating  a  new  user  account,  minimal  information  is  requested  of  users  to  respect  their  privacy, 
but  an  email  is  required  in  case  -  in  the  process  of  reviewing  a  scenario  -  the  reviewer  needs  to 
contact  the  submitter.  The  following  figures  illustrate  the  CSR™  interface. 
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Figure  14.  Account  creation 


Close 


Configure  Google  Login 


or 

Username 


Email 


Password 


Create  account 


IP  Clinical  Seer 


Scenario  Repository 

of  a  clinical  situation  or  event. 

nds  to  fill  a  perceived  gap  in  the  v 
)ve  healthcare,  along  with  the  kne 

i/ent  reporting  mechanisms  and  tc 
that  only  caused  distress  on  the  p 
take  action  upon  them. 


Sion  in  'kers,  such  as  clinical  engineers, 

.  ....  ■  .  Many  of  them,  due  to  their  dilate( 

could  be  potentially  developed  to  improve  healthcare,  but  they  lack  the  r 


Figure  15.  Step  1 :  Scenario  described  in  plain  language 
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MDPnP  Clinical  Scenario  Repository  Prototypee  2013  MD  PnP  Program  intoQrTKJDnQ.ofa 


SaveScanarto  ■  ShowQukMinM  I  Step  1;  B—te  Information  I  Step  2:  Add  Further  Detatts 


Step  3:  Propose  a  Sofutton  I  Finish  and  Submit 


Title 

Synchronization  with  Safety  InterlockI  /} 

Baacription _ 

'A33>year>old  woman  had  a  laparoscopic  cholecy$t«ctomy  [gall  bladder  removal]  performed  under  general  anesthesia.  At  tha  turgeon’t  roQuest.  a  plain  film  x>ray  was  shot  during  a  cholanglogram  [bile  duct  x*ray].  Th« 
anesthealologist  stopped  the  ventllslor  for  the  film.  The  x-ray  technician  was  unsbie  to  remova  the  film  because  of  its  position  beneath  the  table.  The  anesthesiologist  attempted  to  help  her  but  found  it  difficuR  because  the 
gears  on  the  table  had  jammed,  finally,  the  x-ray  was  removsd,  and  the  surgical  procedure  recommenced.  At  some  point,  the  anesthesiologist  glanced  at  the  EKQ  and  noticed  severe  bradycardia.  He  realized  he  had  never 
restarted  tha  ventilator.  (The  ventilator  is  typically  stopped  for  20-60  seconds  to  prevent  motion-induced  blurring  of  the  image.)  ITiis  patient  ultimately  expired. 


Disclaimer  Privacy  Statement  Contact  -  About  MD  PrtP  Feedback 


The  workflow  of  the  scenario  submission  process  is  clear,  highlighting  the  different  scenario  steps 
using  color  codes:  a  first  step  with  basic  information  consisting  of  a  high  level  description  of  the 
scenario  in  plain  language,  a  second  optional  step  in  which  users  can  volunteer  more  technical 
information  such  as  that  related  to  the  nature  of  the  adverse  events  or  the  actors  involved  in  the 
scenario,  and  a  third  optional  step  in  which  users  can  discuss  possible  solutions  for  the  event.  Each 
step  includes  contextual  help  that  guides  the  user  in  the  process  of  entering  the  correct  information 
into  the  right  sections. 
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Figure  16.  Step  2:  Advanced  Details  page  with  contextual  help 
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Additional  Information 

Step  2  of  3  (optional):  Add  additional  information  about  the  scenario. 

•  Add  more  detailed  information  about  contributing  factors  or  events  that  happened  or  could  happen  in  this  or  very  similar  scenarios. 

•  This  step  is  completely  optional.  No  fields  are  mandatory.  Complete  the  information  in  the  tabs  that  you  think  are  relevant  to  describe  the  event  and  igr 
information  to  add. 

•  Tabs  can  be  visited  in  any  order.  Visting  all  of  them  may  not  be  necessary  to  accuratelly  describe  the  scenario. 
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The  CSR™  has  a  user-friendly  navigation  menu  that  helps  both  users  and  administrators  understand 
where  they  are  in  the  application  and  what  their  options  are.  This  makes  it  easier  for  administrators  to 
track  new  submissions  pending  revision. 

Figure  17.  A  glimpse  of  different  options  on  the  navigation  menu 


The  interface  for  revising  submitted  scenarios  is  a  single-page  report.  As  opposed  to  the  scenario 
submission  process,  where  the  use  of  different  steps  and  tabs  helps  keep  interfaces  simple,  avoiding 
overwhelming  requests  for  data,  the  scenario  review  panel  displays  all  the  scenario  information  in  a 
single  report,  so  the  administrators  reviewing  the  scenario  don’t  risk  skipping  important  information  by 
navigation  through  different  steps. 
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Figure  18.  New  panel  for  scenario  revision 


In  order  to  simplify  the  life  cycle  of  scenarios,  the  governance  process  for  submitted  scenarios 
enables  administrators  to  modify  either  submissions  or  approved  scenarios,  avoiding  the  need  of  re¬ 
approving  modified  submissions.  Based  on  the  recommendations  of  contributors  to  the  CSR™, 
administrators  cannot  delete  scenarios  from  the  database,  nor  can  users  delete  their  own 
contributions  once  they  have  been  submitted.  This  is  to  protect  the  content  collected  by  the  CSR™. 
No  user  is  allowed  to  perform  irreversible  actions  that  delete  content  from  the  scenario  collection. 
Scenarios  that  are  not  suitable  for  the  CSR™  are  “hidden”  from  users,  but  are  available  to  the 
researchers  who  are  developing  this  web  tool  so  that  these  kinds  of  contributions  can  help  identify 
new  governance  problems  or  needs. 

Understanding  the  visual  aspect  is  key  to  providing  a  satisfying  CSR™  user  experience  when 
submitting  new  contributions.  Design  enhancements  have  included  an  improved  navigation  bar 
(providing  a  clear  way  to  contact  the  program  for  parties  who  are  interested  in  collaborating  with  the 
development  of  this  web  tool,  contributing  content  to  the  repository,  assisting  with  usage  of  the  tool,  or 
simply  interested  in  the  work  being  done  at  this  research  program).  The  tabbed  panel  displays  the 
kinds  of  advanced  information  that  can  be  submitted  in  a  scenario  (in  order  to  clarify  the  scenario 
submission  workflow  or  to  facilitate  users’  understanding  of  the  non-mandatory  information  they  can 
volunteer). 

Figure  19.  Comparison  of  the  Scenario  Hazards  interface  before  and  after  updates  completed 
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Save  Scenario  I  Hide  Guidelines  H  Step  1:  Basic  information  I  Step  2:  Add  Further  Details  I  Step  3:  Propose  a  Solution 


Additional  Information 

Step  2  of  3  (optional):  Add  additional  information  about  the  scenario. 

•  Add  more  detailed  information  about  contributing  factors  or  events  that  happened  or  could  happen  in  this  or  very  similar  scenarios. 

•  This  step  is  completely  optional.  No  fields  are  mandatory.  Complete  the  information  in  the  tabs  that  you  think  are  relevant  to  describe  the  event  and  igr 
information  to  add. 

•  Tabs  can  be  visited  in  any  order.  Visting  all  of  them  may  not  be  necessary  to  accuratelly  describe  the  scenario. 
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Figure  19  illustrates  some  of  the  improvements  performed  on  the  interfaces.  For  this  particular 
interface  the  size  of  the  text  field  for  the  description  of  hazards  was  expanded  and  color  was  used  to 
highlight  the  input  fields.  Also,  the  visual  aspect  of  the  interface  changed  to  look  more  like  a  tabbed 
panel  (which  for  the  user  clarifies  where  the  information  lies). 

Along  with  the  migration  process  new  features  were  implemented.  The  latest  release  of  the  prototype 
allows  downloads  of  approved  scenarios  as  either  a  single  scenario  or  all  approved  scenarios 
contained  in  the  database  (see  Figure  20). 

Figure  20.  Scenario  Download  features  (from  the  main  menu  or  from  the  View  Scenario  Interface) 


In  order  to  facilitate  sharing  scenarios  among  researchers,  apart  from  the  Download  Scenario  ieature, 
the  CSR™  was  enhanced  to  improve  its  web  presence,  with  upgrades  such  as  a  Twitter  Summary 
Card,  which  could  increase  the  impact  of  sharing  online  scenarios  contained  in  the  CSR™. 

Figures  21  and  22  show  CSR™  scenarios  submitted  by  physician  members  of  the  ASA  Committee  on 
Patient  Safety  and  Quality. 
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Figure  21.  Individual  submitted  scenario 
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Scenario  UID:  kZRNduQzxcqx72STb  Saved  leal:  06-11-201 S,  03:0205  Status:  approved  users  acknowledged  and  upvoted  this  scenario 

Title  of  the  Scenario:  Bradycardia  during  laparoscopic  surgery  due  to  high  flow  rate  ol  C02  insufflation 
Description  of  the  Scenario 

A  S9-yeaT-old  woman  (154  cm  and  56  kg),  without  any  remarkable  past  history  except  well  controlled  hypertension,  has  come  to  take  a  laparoscopic  colpopexy.  Midazolam  2.5 
mg  was  administered  intramuscularly,  30  minutes  before  she  transferred  to  the  operation  room.  On  arrival,  initia]  blood  pressure  (8P)  and  heart  rate  (HR)  were  120/90  mmHgand 
SS  beats  per  minute  (bpm),  respectively,  and  peripheral  oxygen  saturation  (Sp02)  was  98%.  Propofol  120  mg  and  rocuronlum  40  mg  were  Injected  for  Induction.  Intubation  was 
done  with  7.0  mm  endoiratfieai  tube,  and  tidal  volume  (9  ml/kg)  and  respiratory  rale  were  regulated  to  maintain  a  normal  end-tidal  C02  (ETC02).  Anesthesia  was  maintained 
wNh  50%  oxygen  and  sevofturane  2  vol%  and  remifentanil  was  administered  as  a  0.05  pg/kg/min  Infusion,  simultaneously.  ETC02  was  maintained  about  35  mmHg  arxl  peak 
inapiratory  pressure  (PIP)  was  15  cmH20.  Trocar  (SAFE  PASS  TROCARR,  Vaxcon  co.,  Incheon.  Korea),  size  of  11  mm,  was  inserted  to  1  cm  below  the  umbilicus  to  induce 
pneumoperitoneum.  C02  Insufflation  was  started  with  an  insufflator  (insufflator  ML-GX,  MGB  Endoscope  Co.  Ltd.  Seoul,  Korea),  and  then  her  BP  and  HR  suddenly  decreased  to 
90/60  mmHg  and  42  bpm,  respectively.  PIP  has  increased  to  20  cmH20.  but  ETC02  and  Sp02  did  not  change.  It  was  thought  to  be  a  consequence  of  peritoneal  stretching, 
owing  to  pneumoperitoneum,  so  C02  insufflation  was  seized.  Remifentanil  infusion  was  stopped  and  atropine  0.5  mg  was  injected.  Then,  BP  arxl  HR  became  120/80  mmHg  and 
90  bpm,  respectivefy.  C02  insufflation  was  started  again,  but  bradycardia  and  hypotension  developed  yet  again,  and  BP  and  HR  decreased  to  62/32  mmHg  and  23  bpm, 
respectively.  Pressure  limit  of  insufflator  kept  12  cmH20  during  C02  Insufflation,  but  we  found  the  flow  rate  of  C02  insufflaPon  was  too  high  (20  L/mki).  Her  vital  signs  became 
stabilized  again  after  stopping  insufflator  and  hyperventilation  with  100%  02.  Row  rate  was  adjusted  to  start  as  1  Umln  and  increased  to  3  L/min  after  2  minutes.  While  adequate 
pneumoperlloneum  was  achieved,  vital  signs  were  stable  without  hypotension  or  bradycardia.  There  were  no  sudden  bradycardia  or  hypotension  during  surgery  and  she  was 

nmlarTed  to  the  recovery  room  without  any  hazardous  event.  [_ 


HAZARDS 


Current  hazards  of  the  scenario  (1  entries) 


It  Is  well  known  that  laparoscopic  surgery,  using  C02  to  meke  s  pneumoperitoneum,  has  risks  of 
pathophysiological  cardiovascular  changes,  such  as  severe  bradycerdls,  arrhythmia,  and  cardiac 
requiring  cardiopulmonary  rasuscttaUon 
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Figure  22.  List  of  submitted  scenarios 
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While  giving  a  lunch  break  to  someone  in  the  Gl  la... 

0 

0 

/C^ 

rC^  /G\ 

With  the  completion  of  Aim  2,  we  demonstrated  that  the  CSR™  has  appeal  and  value  to  the  medical 
device  commercial,  standards,  health  care  delivery  organizations,  and  patient  safety  sectors.  We  built 
on  this  foundation  to  perform  a  pilot  with  the  ASA  Committee  on  Patient  Safety  and  Quality  in 
September  2016  under  Option-Year  3  of  USAMRMC  award  W81XWH-09-1-0705. 

Open  Source  Code  Dissemination,  Aim  3:  Disseminate  open-source  code  developed  by  the  MD 
PnP  program  and  collaborators,  including  the  prototype  Data  Logger,  in  order  to  facilitate  further 
development  by  others. 
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We  began  working  with  Open  Health  Tools  (OHT)  in  March  2012  to  consider  a  process  for  sharing 
code  and  other  tools.  This  relationship  informed  our  thinking  about  the  challenges  of  sharing  code  and 
the  possible  approaches.  In  addition,  our  NIH  Quantum  U01  sponsors  strongly  and  consistently 
encouraged  us  to  share  code  and  other  artifacts  from  that  work,  but  this  award  enabled  us  to  do  the 
necessary  research  and  organization  to  develop  a  plan  and  an  open-source  approach  for  doing  so. 

We  began  in  September  2012  posting  several  projects  on  GitHub,  a  popular  open-source  project 
hosting  platform.  However,  we  subsequently  identified  limitations  in  tracking  page  views  and 
downloads  of  source  code.  For  this  reason,  we  started  hosting  projects  in  March  2013  on 
SourceForge,  which  supports  more  metrics:  http://sourceforae.net/proiects/mdpnp/.  Unlike  GitHub, 
SourceForge  allowed  us  to  easily  share  artifacts  that  were  not  source  code.  For  instance,  we  obtained 
EGG  and  pulse  oximeter  data  from  a  GE  Central  Station  and  patient  monitor,  and  posted  this  data  on 
SourceForge  for  use  by  other  researchers. 

We  subsequently  added  a  diverse  set  of  software  to  our  code  repository  on  SourceForge,  and  this  site 
became  the  focus  of  all  development  activity  for  MD  PnP  for  this  award,  our  NIH  U01,  and  other 
projects.  Our  repository  includes  software  components  for  interfacing  with  devices  in  our 
Interoperability  Lab,  as  well  as  the  speculative  software  we  built  to  connect  those  devices  and 
implement  demonstration  applications.  By  making  our  work  available  at  various  phases  of 
development,  we  aimed  to  facilitate  involvement  by  the  broader  research  community.  We  recorded 
hundreds  of  downloads  from  dozens  of  countries  within  several  months  of  launching  the  repository 
(see  Figure  23  for  activity  over  this  time  period).  This  site  has  been  a  key  point  of  synchronization  with 
our  collaborators. 

Figure  23.  Weekly  SourceForge  Access  Activity  March  -  August  201 3 


^"Unique  Visitors  ^"Total  Software  Downloads 


A  coherent  build  system  makes  it  easier  for  community  members  to  modify  the  code  because  it 
automatically  creates  an  environment  on  their  computer  amenable  to  building  the  software  (gathering 
third  party  libraries,  configuring  the  compiler,  etc).  Continuous  integration  enabled  us  to  monitor 
changes  made  to  the  code  repository  and  it  reports  in  real  time  on  any  changes  to  the  code  that 
prevent  its  building  successfully  or  any  failed  unit  tests.  We  exercised  these  processes  among  our 
own  team  as  preparation  for  involvement  of  the  broader  community. 

Although  we  did  not  initially  publicize  our  repository  while  we  were  adding  material  and  beta-testing  it 
with  our  collaborators,  potential  users  were  still  finding  our  code  and  downloading  it. 
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During  the  second  year  of  this  award,  our  SourceForge  site  (http://mdpnp.sourceforae.net)  saw  955 
downloads  of  our  prototype  OpenICE  platform  and  tools  (see  Figure  24  below).  Anyone  who 
downloaded  that  software  package  could  use  our  basic  device  simulators  to  begin  development  of 
clinical  apps  for  the  platform.  In  addition  to  sharing  with  the  public  at  large,  we  engaged  in  specific 
interactions  to  pave  the  way  for  development  of  the  first  ICE  AX  apps  as  well  as  the  first  frameworks. 
We  found  ourselves  challenged  to  balance  supporting  these  nascent  external  activities  against  our 
need  to  use  insights  gained  to  enhance  and  iterate  on  the  platform  itself.  With  each  engagement  we 
streamlined  the  documentation  of  the  platform  to  immediately  surface  its  value  to  groups  who  might 
benefit  from  its  use  for  clinical  research. 

Figure  24.  Weekly  SourceForge  Access  Activity  March  -  August  2014 


Weekly  Open  Source  Activity 


^^Unique  Visitors  ^^Total  Software  Downloads 


Following  are  several  examples  of  the  use  of  our  code-sharing  resources  by  researchers: 

•  A  researcher  at  the  University  of  Florida  at  Gainesville  successfully  downloaded,  built  and  ran 
our  code  from  SourceForge;  he  was  building  a  system  for  automatic  patient  assessment  using 
our  open  source  Philips  interfaces  and  DDS  backbone.  In  working  with  them  we  realized  that 
our  current  interface  software  utilizing  the  device’s  Ethernet  port  would  not  be  usable  with  a 
monitor  connected  to  its  central  station  in  such  a  study,  so  we  rewrote  our  interface  to  also 
support  direct  RS-232  connection  to  the  monitor. 

•  In  November  2014  the  MD  PnP  Lab  hosted  undergraduate  students  from  Harvard  and  MIT  for 
a  “hack-a-thon”  organized  in  conjunction  with  the  Hacking  Medicine  group.  This  gave  us  the 
opportunity  to  expose  our  platform  work  to  students  who  were  tasked  with  creating  innovative 
healthcare  apps  based  on  problem  areas  we  outlined.  While  it  was  difficult  for  the  students  to 
produce  complete  apps  within  the  time  constraints  of  the  event,  several  students  expressed 
interest  in  returning  to  the  Lab  and  utilizing  both  our  physical  equipment  and  software  platform 
for  further  work. 

•  Researchers  at  the  United  States  Army  Institute  of  Surgical  Research  began  analyzing  the 
source  code  and  our  software  and  architectural  approach  to  interoperability. 

•  We  became  connected  with  pre-release  work  in  the  area  of  frameworks  being  done  at 
Mathworks  Inc.  on  a  MatLab  interface  to  RTI’s  DDS  middleware.  By  participating  in  that 
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project,  we  were  able  to  ensure  that  when  this  MatLab  “BlockSet”  was  eventually  released,  it 
would  be  compatible  with  the  DOS  middleware  used  in  our  ICE  platform. 

We  built  a  new  website  to  support  remote  use  of  the  MD  PnP  Interoperability  Lab's  capabilities: 
Open  ICE. info.  This  site  was  intended  to  allow  diverse  users  -  potentially  students,  clinicians, 
biomedical  engineers  or  others  interested  in  using  medical  device  data  -  to  easily  access  and  use 
data  from  devices  and  patient  simulators  in  the  MD  PnP  Lab.  This  capability  was  expected  to  permit 
broad  access  to  OpenICE  tutorials,  information,  apps,  and  source  code. 

Figure  25.  Screenshot  from  Open  Ice. info:  a  Web  Resource  for  Education  and  Dissemination 


-  is  an  Open-Source  Integrated  Clinical  Environment, 

-  is  a  prototype  clinical  ecosystem  connecting  medical 
devices  and  clinical  applications, 

-  provides  a  framework  for  the  integration  of  devices  and 
apps  into  the  broader  Medical  Internet  of  Things, 
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We  extended  the  capabilities  of  the  OpenICE  website  (http://openice.info)  to  include  a  community 
support  forum  in  which  OpenICE  users  from  around  the  world  can  submit  questions,  code,  and  other 
information  to  be  discussed  with  the  MD  PnP  team  and  each  other  (http://communitv.openice.info).  In 
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addition,  this  forum,  powered  by  UserEcho,  is  useful  as  a  tool  to  track  the  growth  of  the  worldwide 
Open  ICE  user  community  and  to  identify  shared  development  interests  or  issues.  However,  staffing  a 
response  team  while  performing  our  other  required  funded  work  proved  challenging.  Figures  26-28 
show  illustrative  screen  shots  of  the  forum. 

Figure  26.  Screenshot  of  OpenICE  Community  Forum 
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During  the  first  four  months  of  2015,  the  community  support  forum  for  OpenICE  users  grew 
substantially  (Table  1).  In  addition  to  a  200%  increase  in  unique  users  and  300%  increase  in 
community  postings,  we  identified  several  shared  development  interests  /  issues  across  the 
community,  such  as  OpenICE  connection  to  the  Philips  Intellivue  line  of  patient  monitors. 
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Table  1.  Community  statistics  for  OpenICE  support  forum  website 
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Figure  27.  Screenshot  of  OpenICE  community  forum  showing  feedback 
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Two  months  later,  the  community  support  forum  for  OpenICE  users  had  experienced  a  further  164% 
growth  rate  in  unique  users  and  224%  growth  rate  in  community  postings,  as  shown  in  Table  2.  Some 
added  features  of  the  OpenICE. info  forum  included: 

•  Front-page  access  to  all  source  code,  documentation,  and  streaming  data 

•  Live  twitter  feed  of  updates  from  the  OpenICE  team 

•  OpenICE  Developer  Blog 

•  Video  tutorials  of  OpenICE  and  lab  tour  of  MD  PnP 
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.  More  detailed  documentation  for  OpenICE  system  architecture,  demonstration  apps  and  app 
architecture,  device  adapter  set-up  and  configuration,  white  paper  description  of  ICE 
Supervisor,  and  notes  on  functionality  and  use  of  the  Beaglebone  appliance 

Table  2.  Community  statistics  for  OpenICE  support  forum  website 
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Figure  28.  Screenshot  of  OpenICE  community  forum 
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ICE  External  Interface  Data  Transfer,  Aim  4:  Define  and  document  external  interfaces  to  bi¬ 
directionally  transfer  medical  device  and  patient  contextual  data  between  the  integrated  clinical 
environment  and  external  systems  of  national  interest.  Demonstrate  the  interface  to/from  one  or  more 
of  these  systems  (depending  on  which  are  ready  and  accessible). 

To  achieve  this  aim,  we  built  on  learnings  from  a  CIMIT-sponsored  project  on  Veterans  Healthcare 
Data  Exchange,  which  involved  connectivity  and  exchange  of  data  between  the  Partners  Healthcare 
electronic  health  record  and  both  the  VistA  and  AHLTA  systems.  While  limited  in  scope  by  design, 
that  earlier  project  provided  a  good  foundation  for  the  bi-directional  transfer  work  on  this  project, 
including  the  establishment  of  good  collaborations  with  contacts  at  both  USAMRMC  and  the  VA. 

We  built  on  this  earlier  CONNECT  and  DIRECT  work  to  develop  a  technology  demonstration  of  our 
use  of  CONNECT  in  two  ICE  systems  in  a  demonstration  at  HIMSS13  (Healthcare  Information  & 
Management  Systems  Society  annual  conference)  in  March  2013.  CONNECT  uses  the  Nationwide 
Health  Information  Network  (NwHIN)  standards  and  specifications,  including  the  DIRECT  project 
specifications,  to  exchange  health  data  (see  https://www.healthit.qov/FHA/CONNECT).  Our  demo 
was  selected  by  the  Office  of  the  National  Coordinator  for  Health  IT  (ONC)  to  be  part  of  the  ONC’s 
demonstration  area  in  the  Interoperability  Showcase.  The  MD  PnP  team  collaborated  with  DocBox 
Inc.  and  Kansas  State  University  to  produce  a  demonstration  on  "Transferring  a  Patient’s  Device 
Settings  between  Care  Environments,"  which  conveyed  the  significance  of  device  data  as  part  of 
national  interoperability  efforts. 

The  demonstration  (see  Figure  29)  showed  connectivity  between  two  ICE  systems  (standards-based 
Integrated  Clinical  Environments)  in  the  OR  and  ICU,  and  use  of  the  NwHIN  to  automatically  return 
current  device  data  in  response  to  a  clinician  query.  The  demo  showed  reading  and  changing  of 
device  settings  between  the  OR  and  ICU,  external  query  via  CONNECT  to  the  TATRC  test  EMR  with 
a  return  of  allergy  information,  coordination  between  multiple  apps,  and  coordination  via  CONNECT 
between  a  commercial  ICE  implementation  (developed  by  DocBox)  and  a  research  ICE 
implementation  using  the  open-source  Medical  Device  Coordination  Framework  (MDCF)  provided  by 
collaborators  at  Kansas  State  University. 

Figure  29.  HIMSS13  Demo  on  Transferring  Device  Settings  between  Care  Environments 


Transferring  Patient's  Device 
Settings  Between  Care 
Environments:  OR  to  ICU 
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The  HIMSS  demo  was  visited  by  over  300  HIMSS  attendees,  and  was  one  of  the  few  ONC  demos 
visited  by  the  HHS  National  Coordinator  for  Health  IT,  Farzad  Mostashari,  MD  -  who  said  it  was  the 
“most  exciting”  demo  in  the  ONC  area.  Afterwards  we  published  our  CONNECT  code  on  SourceForge 
(see  Aim  3  above). 

We  continued  to  seek  opportunities  for  further  bi-directional  connectivity.  An  appropriate  challenge 
was  that  hospitals  do  not  typically  have  a  monolithic  record  system  requiring  only  a  single  interface. 
Instead,  there  are  large  catalogs  of  available  services,  each  with  its  own  specification.  Thus, 
developing  bilateral  interfaces  between  ICE  and  each  of  these  services  individually  requires  never- 
ending  development.  Instead  we  worked  to  integrate  a  DOS  system  into  a  larger  Enterprise  Service 
Bus.  Aligning  ourselves  with  ongoing  efforts  by  DOS  vendors,  we  worked  with  Apache  Camel  to 
create  an  endpoint  for  our  system.  Camel  allowed  us  to  align  our  system  interface  with  interfaces  to 
myriad  other  systems  without  any  tight  coupling.  For  example,  our  Camel  interface  could  be 
connected  to  the  Camel  component  for  HL7  to  interface  with  an  Electronic  Health  Record  (EHR).  With 
a  simple  reconfiguration,  we  could  also  use  150  other  Camel  components,  allowing  us  to  connect  with 
systems  via  technologies  ranging  from  flat  files  to  web  services.  We  connected  our  Camel  interface 
with  the  Camel  component  for  “websockets”,  which  are  bi-directional  protocols  for  streaming  data  to  a 
web  browser  client.  Such  an  interface  allowed  us  to  easily  export  data  from  ICE  to  a  wide  range  of 
other  terminals  running  on  desktops,  laptops,  tablets,  and  smartphones.  This  research  demonstrated 
a  viable  pathway  for  making  the  type  of  interface  shown  in  our  next  HIMSS  ONC  demonstration 
opportunity  -  a  Real-Time  Blue  Button. 

The  Office  of  the  National  Coordinator  for  Health  IT  invited  us  to  participate  again  in  their  ONC/FHA 
(Federal  Health  Architecture)  area  of  the  Interoperability  Showcase  at  the  annual  HIMSS  conference 
and  exhibition  in  February  2014.  We  developed  a  new  ICE  application  for  this  demonstration  that  runs 
on  Android  tablets  and  smartphones  and  streams  physiological  data  (including  waveforms)  from 
medical  devices  connected  at  our  MD  PnP  Lab  in  Cambridge,  MA,  as  well  as  data  from  medical 
devices  connected  locally  at  HIMSS.  While  much  of  our  ongoing  work  focuses  on  the  patient  bedside, 
we  wanted  to  demonstrate  to  the  HIMSS  audience  how  a  bedside  ICE  network  can  connect  to 
external  resources.  For  this  demo  we  built  a  Real-Time  Blue  Button  -  a  prototype  ICE  External 
Interface  suitable  for  live  streaming  data,  an  Android  app  to  display  the  data,  and  an  ICE  application 
that  packages  up  the  data  and  sends  it  to  the  phone  or  tablet.  We  had  the  opportunity  to  show  this 
demonstration  to  the  National  Coordinator  for  Health  IT,  Dr.  Karen  DeSalvo,  and  to  Col.  Dan  Krai, 
TATRC  Director,  as  well  as  many  other  attendees  over  the  course  of  three  days  (see  Figure  30). 

Figure  30.  ICE  External  Interface  Demonstration  at  HIMSS  2014 
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This  type  of  system  is  suitable  for  remote  display  of  patient  data,  including  waveforms  and  alarms, 
and  could  be  used  either  for  live  display  or  for  streaming  data  to  a  research  database.  A  robust  ICE 
system  can  constitute  a  more  informative  peer  to  other  hospital  systems.  For  example,  an  electronic 
medical  record  (EMR)  system  could  archive  real-time  data  from  the  ICE  system.  The  EMR  can  also 
benefit  from  the  richer  set  of  information  provided  by  ICE  as  compared  with  individual  devices.  At 
HIMSS  we  demonstrated  that  even  patient  engagement  systems,  such  as  those  inspired  by  the  VA 
Blue  Button  initiative,  can  benefit  from  the  availability  of  the  suite  of  rich  contextual  data  made 
available  in  real  time  by  an  ICE  system.  Afterwards  we  made  the  Real-Time  Blue  Button  demo 
publicly  available  (see  video  of  this  demo  at  http://vimeo.com/87434601). 

In  socializing  the  concept  of  remote  bi-directional  connectivity  to  our  MD  PnP  Interoperability  Lab,  we 
found  that  there  was  great  interest  in  this  capability,  especially  as  a  means  to  provide  simulated  data 
to  computer  science  and  engineering  research  groups  that  have  limited  access  to  clinical  devices, 
data,  and  domain  expertise.  In  addition  to  working  on  collaborations  with  UlUC  and  UMass  Amherst, 
we  responded  to  the  initial  Presidential  Innovation  Fellows’  SmartAmerica  Challenge  with  a  white 
paper  proposing  a  “Virtual  Hospital  CPS  Test  Bed”  building  directly  on  Aim  4  of  this  award;  this  led  to 
the  inclusion  of  Dr.  Goldman  in  the  inaugural  SmartAmerica  Challenge  project  initiation  meeting  held 
at  the  White  House  in  December  2013  and  the  involvement  of  our  team  in  subsequent  SmartAmerica 
activities. 

As  a  result  of  his  presentation  at  the  White  House  SmartAmerica  Challenge  meeting.  Dr.  Goldman 
was  invited  to  co-chair  the  Closed-Loop  Healthcare  team  formed  there.  In  March  2014  we  hosted  this 
team  for  a  three-day  meeting  and  “hackathon”  in  our  Interoperability  Lab,  where  we  made  progress 
with  multiple  collaborators.  The  team  from  NIST  was  able  to  streamline  the  acquisition  of  data  for  later 
replay  by  their  playback  application  for  the  ICE  Data  Logger.  They  had  acquired  a  Philips  patient 
monitor,  so  we  configured  a  BeagleBone  for  them  with  an  ICE  Equipment  Interface  for  further  testing 
and  development.  We  also  had  an  opportunity  to  bring  together  two  vendors  of  DDS  middleware,  RTI 
and  PrismTech,  to  assess  interoperability  between  their  implementations.  We  discovered  a  few  small 
incompatibilities  and  identified  a  solution  pathway  in  the  course  of  the  meeting.  Our  Closed  Loop 
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Healthcare  collaborators  shared  integration  strategies  at  the  enterprise  level,  both  for  data  integration 
and  for  data  storage.  The  prototype  developed  during  the  March  hackathon  was  demonstrated  at  the 
White  House-hosted  SmartAmerica  Expo  in  Washington,  DC  in  June  2014. 

The  ICE  External  Interface  prototype  we  built  for  our  HIMSS  demo  was  highly  customized  to  that 
application  and  not  suitable  for  large  numbers  of  patients  or  client  applications,  so  we  worked  to 
connect  ICE  to  a  generalized  Enterprise  Service  Bus  (ESB).  While  DDS  is  an  appropriate  backbone 
for  a  high-criticality  distributed  system,  our  connection  to  an  ESB  created  alignment  between  our 
system  and  a  library  of  modular  components  for  exposing  ICE  data  to  other  systems  via  a  wide  range 
of  existing  technologies. 

In  April  2014  two  members  of  our  team  presented  this  work  at  the  International  Conference  on  Cyber- 
Physical  Systems  (ICCPS)  in  Berlin.  Our  short  paper  describing  key  considerations,  or  pillars,  for 
selecting  middleware  for  ICE  systems  was  presented  at  the  workshop  on  Medical  Cyber-Physical 
Systems.  A  poster  describing  our  work  on  OpenICE  was  presented  during  the  ICCPS  poster  session. 
We  received  considerable  interest  from  members  of  the  CPS  community  who  understood  that  they 
need  common  data  streams  to  enable  their  work  on  closed-loop  control  systems.  At  the  workshop  we 
also  presented  a  poster  describing  our  work  on  gathering  clinical  requirements,  as  well  as  our  Clinical 
Scenario  Repository  (CSR™).  Several  participants  expressed  interest  in  the  description  of  clinical 
scenarios,  and  some  participants  volunteered  to  become  beta  testers  of  the  CSR™. 

Connecting  with  external  systems  matured  our  approach  to  handling  multiple  patients.  Within  the 
scope  of  a  single  ICE  instance,  only  a  single  patient  is  involved,  but  most  external  systems  are 
managing  entire  patient  populations.  This  research  benefited  our  subsequent  USAMRMC  Joint 
Warfighter  award  to  use  OpenICE  to  provide  re-configurable  COTS-based  clinical  monitoring  and 
decision  support  capability  to  improve  the  efficiency  and  effectiveness  of  monitoring  and  evaluation  of 
patients  in  forward  holding  areas.  Elaborating  on  how  many  ICEs  will  be  coordinated  also  aided  our 
ability  to  communicate  with  health  information  technology  experts,  bridging  a  gap  and  demonstrating 
the  relevance  of  ICE  to  the  real  world  systems  that  drive  clinical  environments  today. 

Our  understanding  of  potential  interactions  between  ICE  and  other  hospital  systems  also  matured 
greatly  during  this  project.  We  first  worked  with  a  developer  at  MGH  to  understand  the  catalog  of 
currently  available  test  interfaces.  Then,  in  2014  Partners  Healthcare  (MGH  and  partner  hospitals) 
began  changing  their  electronic  health  record  (EHR)  systems  to  EPIC,  a  major  undertaking  expected 
to  take  five  years  to  complete.  Because  all  of  the  interfaces  to  the  EHR  would  be  changing,  with  the 
first  round  of  changes  scheduled  for  mid-2015,  this  was  not  the  right  time  to  prototype  new 
connections  to  MGH  systems.  Therefore,  we  reached  agreement  with  USAMRMC/TATRC  to  pursue 
the  work  needed  for  our  milestone  related  to  ADT  systems  by  working  with  support  from  the  U.S. 
Department  of  Veterans  Affairs  (VA)  to  install  VistA  in  our  Lab. 

VistA  (Veterans  Health  Information  Systems  and  Technology  Architecture)  is  an  enterprise-wide 
information  system  built  around  an  EHR  used  throughout  the  VA  medical  enterprise.  It  consists  of 
nearly  160  integrated  software  modules  for  clinical  care,  financial  functions,  and  infrastructure.  The 
MD  PnP  team  chose  to  test  our  ICE  integration  with  VistA,  because  it  is  widely  used  and  is  freely 
available  as  an  open-source  program.  With  several  VistA  variants  available,  we  decided  to  work  with 
OSEHRA  (Open  Source  Electronic  Health  Record  Alliance)  to  install  OSEHRA  VistA.  We  installed  the 
client-server  packages  of  Astronaut-VistA,  one  of  the  open  source  versions  of  VistA  available  with  the 
OSEHRA  suite,  as  well  as  the  GUI-based  client  application  called  CPRS  (Computerized  Patient 
Record  System).  Figures  31  and  32  show  the  healthcare  record  of  our  demo  patient. 
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Figure  31.  Screenshot  of  Demo  Patient’s  EHR  CPRS 


We  successfully  used  the  command  line  interface  to  access  and  manipulate  the  data  on  the  server, 
and  we  were  able  to  access  and  edit  our  demo  patient’s  vital  signs,  including  waveform  data. 

Figure  32.  Screenshot  of  Demo  Patient’s  Vital  Signs  in  CPRS 


We  learned  that  the  various  versions  and  patches  available  for  Astronaut-VistA  have  been  developed 
by  an  open  source  community  and  contain  many  bugs.  The  client-server  versions  that  are  publically 
available  are  not  reliable  in  a  research  setting.  We  consulted  experts  in  this  field  to  guide  us  with  the 
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configuration  of  a  reliable  system,  and  worked  closely  with  the  development  team  at  OSEHRA  to  get 
VistA  installed  and  functional  in  the  MD  PnP  Lab.  The  basic  system  was  installed  and  running  in  the 
fall  of  2014,  and  we  then  focused  on  understanding  the  different  potential  ways  of  integrating  VistA 
with  the  ICE  infrastructure  in  our  Lab. 

As  part  of  our  effort  to  export  an  ADT  feed  from  the  EHR  to  the  Lab,  we  added  the  functionality  to  our 
app  for  importing  streaming  device  data  for  logging  and  analysis  from  medical  devices  in  our  Lab.  We 
planned  to  learn  about  the  EPIC  EHR  system  being  installed  at  Partners  Healthcare,  and  to  obtain 
access  to  a  research  license  for  EPIC  and  test  data  feeds,  as  they  were  made  available. 

We  also  explored  integrating  ICE  with  other  EHR  systems  such  as  that  of  Athena  Health.  As  part  of 
their  MDP  (More  Disruption  Please)  campaign,  Athena  Health  released  a  number  of  API’s  freely 
available  on  Mashery.  Athena  Health  integrates  with  a  number  of  healthcare  software  products  on  the 
market,  such  as  Clockwise. MD,  Intuit’s  DemandForce,  healthgrades,  Entrada,  iTriage,  Vitals,  and 
PatientPoint  Coordinated  Care  Platform.  Their  API  is  RESTful  and  uses  JSON.  The  documentation 
covers  basic  functionality  such  as  authentication,  the  format  of  the  responses  (normally  JSON),  and 
workflows.  There  is  also  a  reference  documentation  section  and  information  for  API  output  (see 
Figures  33  and  34). 


Figure  33:  Athena  Health  API  keys 
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Figure  34.  Athena  Health  Allergy  Documentation 
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^  Chart 
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Allergies  Overview 

Summary 

Allergies  in  atKenanef  ore  a  procKce-ognoslic  list  sourced  from  First  Databank 
(FDB).  Eoch  patient  allergy  in  athenanet  can  contain  a  list  of  reoctions,  artd  tbe 
severity  of  those  reoctions.  If  a  patient  has  no  allergies,  you  can  explicitly  state 
that  using  the  No  KrK>wn  Drug  Allergies  (NKDA)  flag.  Atherns  uses  the  list  of 
patient  allergies  when  orderirig  medications  with  drug>allergy  (as  well  as  drug- 
drug)  interaction  warnings. 

Gottfng  the  list  of  allergies,  reactions,  and  severities 

The  data  we  license  from  FDB  cannot  be  shared  with  our  partners;  that  would 
require  you  to  have  a  separate  license  with  FDB.  NMiat  we  can  share  is  the 
picker  list  of  valid  allergies  that  atheno  accepts.  You  get  a  list  of  matching 
allergens  via: 

GET  /reference/ allergies ?searchvalue- (phrase ) 

The  searchvalue  must  contain  at  least  2  characters,  and  may  contain  spoces. 

This  returns  a  list  of  up  to  10  matches.  The  ollergylD  returned  can  then  be  used 
to  add  allergies  to  the  system.  Simibriy,  you  can  get  the  list  of  valid  reactions 
ond  severities  supported  by  athenanet  via: 

GET  /ref erence/ allergies /reactions 

GET  /ref erence/ allergies /severities 

Figure  35  shows  our  code  for  reading  out  the  patient’s  allergy  history.  We  explored  other  functionality, 
including  writing  into  the  EHR. 
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Figure  35.  Code  for  reading  out  Patient  Allergy  history 


In  April  2015,  at  the  invitation  of  the  Office  of  the  National  Coordinator  of  Health  IT,  the  MD  PnP  team 
again  participated  in  the  HHS  ONC/FHA  area  of  the  Interoperability  Showcase  at  the  annual  HIMSS 
conference. 

In  an  effort  to  eliminate  erroneous  vital  signs  data  from  clinical  data  repositories,  most  EHRs  are 
configured  to  require  that  all  vital  signs  data  be  manually  “validated”  by  a  nurse  or  clinician  before  the 
data  enters  the  EHR.  This  manual  validation  introduces  delays  in  propagating  data  to  clinical  decision 
support  systems  and  introduces  human  selection  bias  by  clinicians  choosing  not  to  validate  correct 
but  irregular  data  points.  The  demonstration  application  of  the  automatic  validation  algorithm  enables 
Integrated  Clinical  Environments  to  provide  EHRs  with  accurate,  pre-validated  vital  signs  data  through 
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the  use  of  digital  signal  processing,  statistics,  and  business  rules.  More  details  can  be  found  on  the 
Open  ICE  website  at  https://www.openice.info/docs/3  apps.html#auto-validate. 


The  screenshot  in  Figure  36  shows  the  Autovalidation  app  display,  where  the  checkmark  indicated  as 
“Final”  has  been  Autovalidated.  “Preliminary”  denotes  data  that  has  not  met  Autovalidation  data 
integrity  criteria. 

Figure  36.  OpenICE  Autovalidation  App  showing  histograms  of  vital  signs  data  from  multiple  monitors 


•  •  •  OpenICE 


At  HIMSS15,  in  collaboration  with  DocBox  Inc,  we  demonstrated  this  EHR  data  auto-validation  tool 
and  OpenICE  app,  and  storage  and  export  functionalities  to  connect  two  ICE  systems  (see  Figure  37). 
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Figure  37.  HIMSS15  Exhibit  of  OpenICE  Autovalidation  App  with  output  transmitted  to  and  displayed 

by  a  DocBox  flowsheet  application 


As  seen  in  Figure  37,  we  enabled  ICE-to-ICE  communication.  The  patient  monitor  (left)  measures 
signals  from  a  patient  simulator  (not  shown).  Patient  monitor  data  is  acquired  by  OpenICE  and 
analyzed  to  automatically  assess  data  quality  over  20-second  epochs.  Data  of  acceptable  quality  is 
transmitted  over  an  open  bus  to  a  prototype  DocBox  ICE  platform,  and  displayed  in  a  DocBox 
flowsheet  application. 
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Figure  38.  Multiple  patient  identities  with  unique  device  assignments 


•  •  • 
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Exit  App  Create  an  ICE  Device  Adapter...  15:56:52 


The  data  generated  from  these  devices  are  being  logged  to  a  csv  file  (Excel),  as  shown  in  Figure  39. 
Figure  39.  Data  Recorder  reading  data  feeds  from  multiple  devices 


•  •  • 
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Exit  App 


Select  a  patient:  Randall  Jones 


Create  an  ICE  Device  Adapter... 


15:54:50 


We  also  created  an  HL7-compliant  data  export  feed  which  can  selectively  send  data  points  by  patient 
and  at  an  adjustable  frequency  (shown  in  Figure  40).  We  validated  our  feed  with  our  test  server,  built 
using  HAPI-FHIR,  a  100%  open-source  Java  implementation  of  the  FHIR  (Fast  Healthcare 
Interoperable  Resources)  specification  (see  https://www.openice. info/docs/3  apps.html#hl7-exporter). 
This  external  interface  was  bundled  as  an  application  included  in  the  OpenICE  distribution.  (FHIR 
implementation  by  EHR  vendors  has  been  slow  but  steady;  we  can  send  HL7  FHIR  data  to  EHRs  as 
they  add  this  capability.) 
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Figure  40.  HL7  format  data  export  capabilities 


•  •  •  OpeniCE 

_ HL7  Exporter  _ 

I  MSH|''-\&|ICE||lt201 5051 21 55358.626-0400||ORU^R01  '^ORU.ROI  |1fT|2.6|123  I 
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Frequency  gg  15^  30,  irn  5m  lOm  15m  20m  30m  1h 

FHIR  DSTU2  •  v2.6  Host:  https://fhir.openice.info/fhir  Port:  0  Start 

ExitApp  Select  a  patient:  RandailJones  ▼  Create  an  ICE  Device  Adapter...  15:53:59 


During  the  summer  of  2015  we  worked  on  integrating  our  export  feed  into  an  open  source  Electronic 
Health  Record,  coordinating  with  the  support  staff  at  OpenMRS  and  OpenEMR  for  seamless 
integration. 

OpenMRS  (Open  Medical  Record  System)  was  created  in  2004  as  an  open  source  medical  record 
system  platform  for  developing  countries.  It  is  a  multi-institutional  non-profit  collaborative  led  by 
Regenstrief  Institute  and  Partners  in  Health.  OpenMRS  is  now  in  use  around  the  world,  including  in 
South  Africa,  Kenya,  Rwanda,  Lesotho,  Zimbabwe,  Mozambique,  Uganda,  Tanzania,  Haiti,  India, 
China,  United  States,  Pakistan,  the  Philippines,  and  many  other  places. 

Some  of  its  key  features  include: 

•  Data  entry:  With  the  HTML  FormEntry  module,  forms  can  be  created  with  customized  HTML 
and  run  directly  within  the  web  application 

•  Data  export:  Data  can  be  exported  into  a  spreadsheet  format  for  use  in  other  tools  (Excel, 
Access,  etc.) 

•  Standards  support:  HL7  engine  for  data  import 
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Figure  41.  Patient  Record  in  OpenMRS 
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OpenEMR  is  a  Free  and  Open  Source  electronic  health  records  and  medical  practice  management 
application  that  can  run  on  Windows,  Linux,  Mac  OS  X,  and  many  other  platforms.  It  is  certified  by  the 
Office  of  the  National  Coordinator  for  Health  IT  and  is  one  of  the  most  popular  open  source  electronic 
medical  records  in  use  today,  with  over  3,700  downloads  per  month.  Internationally,  it  has  been 
estimated  that  OpenEMR  is  installed  in  more  than  15,000  healthcare  facilities,  translating  into  more 
than  45,000  practitioners  using  the  system,  and  serving  over  90  million  patients. 


Figure  42.  Patient  Record  in  OpenEMR 
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The  server  side  is  written  in  PHP  and  can  be  employed  in  conjunction  with  a  LAMP  "stack",  although 
any  operating  system  with  PHP  is  supported.  It  accepts  data  in  sql  format  that  can  be  exported  from 
OpenICE. 

Figure  43.  Import  capabilities  of  OpenEMR 
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File  may  be  compressed  (gzip.  bzip2.  zip)  or  uncompressed. 

Acompressed  file's  name  must  end  in  .[format].[compression].  Example:  .sql.zip 

Browse  your  computer:  Choose  File  no  file  selected  (Max:  30MiB) 

Character  set  of  the  file:  utf-8  * 

Partial  Import; 

✓  Allow  the  interruption  of  an  import  in  case  the  script  detects  it  is  close  to  the  PHP  timeout  limit.  (This  might  be  a  good  way  to  import 
large  files,  however  it  can  break  transactions.) 

Skip  this  number  of  queries  (for  SQL)  or  lines  (for  other  formats),  starting  from  the  first  one:  0  C 
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SQL  ; 

Format-Specific  Options: 


Key  Research  Accomplishments 

•  Implementation  of  a  prototype  ICE  Data  Logger.  In  collaboration  with  NIST,  we  defined 
requirements  for  and  built  several  prototypes  of  medical  device  system  forensic  data  loggers 
(“black  box  recorders”)  that  leveraged  the  standards-based  ICE  architecture  and  software.  An 
extensive  review  of  existing  forensic  data  logging  approaches  informed  our  prototypes.  We 
used  our  open-source  OpenICE  platform  for  this  research.  With  NIST,  we  researched  the  best 
approach  to  long-term  storage  of  logged  data  and  performed  experiments  to  compare  the 
performance  of  MySQL  and  other  data  stores  for  recording  and  searching  data.  This  allowed 
us  to  perform  end-to-end  testing  of  the  entire  OpenICE  system  from  the  equipment  interface 
through  to  the  Data  Logger  as  we  revised  our  OpenICE  platform. 

•  Clinical  Scenario  Repository™.  We  presented  a  beta  version  of  the  Clinical  Scenario 
Repository™  (CSR™)  at  the  annual  meeting  of  the  Society  for  Technology  in  Anesthesia  and 
a  meeting  of  the  Society  for  Critical  Care  Medicine,  where  valuable  feedback  was  gathered. 
We  successfully  transitioned  the  CSR™  web  application  to  our  Lab  managed  servers,  as  we 
discovered  that  the  Google  Application  Engine  used  in  the  prototype’s  early  stages  could  not 
support  newly  identified  privacy  and  security  requirements.  We  implemented  several 
prototypes  based  on  feedback  from  physician  evaluators  at  the  Committee  on  Patient  Safety 
and  Quality  of  the  American  Society  of  Anesthesiologists  (ASA),  the  AHRQ  Patient  Safety 
Organization  (PSO)  experts,  the  CRICO  risk  management  foundation,  and  the  ISO  TC  121 
international  medical  device  standards  development  committee. 

•  Open-Source  Code-Sharing  Repository.  We  created  an  open-source  code-sharing 
environment  using  SourceForge  and  Github,  where  our  project  code,  including  ICE  Data 
Logging  capability,  is  freely  available  for  downloading  by  research  and  manufacturer 
communities.  To  date,  we  have  recorded  hundreds  of  downloads  from  around  the  world. 
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•  HIMSS13  Demonstration.  We  implemented  CONNECT  as  part  of  an  ICE  system 
demonstration  in  the  ONC/FHA  demonstration  area  in  the  Interoperability  Showcase  at 
HIMSS13  (Healthcare  Information  &  Management  Systems  Society  annual  conference). 
CONNECT  leverages  the  Nationwide  Health  Information  Network  (NwHIN)  standards  and 
specifications,  to  exchange  health  data.  At  HIMSS  we  were  able  to  share  our  experience  in 
implementing  CONNECT  with  other  researchers  and  manufacturers.  The  HIMSS  demo  was 
visited  by  over  300  HIMSS  attendees,  and  was  visited  and  applauded  by  the  National 
Coordinator  for  Health  IT,  Farzad  Mostashari. 

.  Demonstrations  for  Federal  Agencies.  In  August  2013  we  spent  two  days  at  NIH  presenting 
a  series  of  demonstrations  of  our  work  for  invited  representatives  from  federal  agencies. 
These  demonstrations  included  the  initial  prototype  Data  Logger  and  Clinical  Scenario 
Repository.  Over  60  visitors  from  DoD,  FDA,  NIST,  NIH,  and  other  federal  agencies  attended, 
and  we  received  insightful  and  positive  feedback  that  informed  subsequent  research. 

•  HIMSS14  Demonstration.  In  the  ONC/FHA  area  of  the  Interoperability  Showcase  at 
HIMSS14,  we  demonstrated  a  new  ICE  app  inspired  by  the  VA  Blue  Button  data-sharing 
initiative.  In  contrast  to  static  patient  records,  our  “Real-Time  Blue  Button  for  Patients  and 
Families”  streamed  physiological  data  (including  waveforms)  from  medical  devices  connected 
remotely  at  our  Lab  in  Cambridge,  MA,  as  well  as  data  from  medical  devices  connected  locally 
at  HIMSS.  For  this  demo  we  built  a  prototype  ICE  External  Interface  suitable  for  live  streaming 
data,  an  Android  app  to  display  the  data,  and  an  ICE  application  that  packaged  the  data  and 
sent  it  to  the  phone  or  tablet.  We  were  honored  to  demonstrate  this  research  to  the  National 
Coordinator  for  Health  IT,  Dr.  Karen  DeSalvo,  and  Col.  Dan  Krai,  TATRC  Director. 

.  HIMSS15  Demonstration.  Once  again  in  the  ONC/FHA  area  of  the  Interoperability  Showcase 
at  HIMSS15,  we  demonstrated  Automated  Validation  of  Medical  Device  Data  for  EHRs  using 
an  OpenICE  installation  with  a  GE  Dash  patient  monitor  and  an  ICE  Supervisor  running  a  new 
Autovalidation  app  and  transferring  validated  data  to  a  DocBox  ICE  implementation  running  a 
charting  app.  The  exhibit  demonstrated  the  ability  to  interconnect  two  different  ICE  systems 
and  the  benefit  of  using  ICE  as  a  platform  to  prototype  apps  for  HIT  innovation.  To  minimize 
artifactual  data  in  the  EHR,  vital  signs  data  is  typically  manually  validated  -  usually  by  an  RN  - 
prior  to  permanent  inclusion  in  the  EHR.  The  Autovalidation  app,  by  analyzing  1200  vital  signs 
data  points  within  a  20-second  window,  identified  artifact-free  data  that  was  tagged  “validated” 
for  inclusion  in  the  DocBox  charting  application.  Autovalidation  can  overcome  nursing  workflow 
limitations  to  enable  inclusion  of  substantially  more  high-quality  data  in  the  EHR.  This  research 
demonstrated  the  versatility  of  ICE  platforms  and  the  potential  value  of  access  to  all  data  from 
patient  monitors  to  enable  advanced  apps  for  patient  care. 

•  Smart  America  Challenge.  The  Closed  Loop  Healthcare  team,  comprised  of  groups  from 
academia,  industry,  research  and  government,  was  formed  at  the  Presidential  Innovation 
Fellows’  SmartAmerica  Challenge  initial  meeting  in  December  2013.  During  a  three-day 
meeting  and  “hackathon”  hosted  in  our  MD  PnP  Lab  “sandbox”  in  March  2014,  the  team 
developed  prototypes  for  demonstration  at  the  White  House-led  SmartAmerica  Expo  in 
Washington,  DC  in  June.  We  moved  NIST  forward  on  the  Data  Logger  work,  brought  together 
vendors  of  DDS  middleware  to  demonstrate  interoperability  between  their  implementations, 
and  Closed  Loop  Healthcare  collaborators  shared  integration  strategies  at  the  enterprise  level, 
both  for  data  integration  and  for  data  storage. 

•  Ebola  Medical-Technology  Response  and  Global  City  Teams  Challenge  (GCTC).  In 

response  to  a  White  House/OSTP  request  to  contribute  to  solutions  for  the  rapidly  progressing 
Ebola  Virus  Disease  (EVD)  epidemic  in  2016,  we  formed  a  twenty-collaborator  team  which 
during  twenty  days  developed  and  demonstrated  safety-enhancing  and  patient-care-improving 
research  prototypes.  The  project  inspiration  was  based  on  our  participation  in  the  NIST  GCTC 
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initiative  on  “remotely  caring  for  our  most  vulnerable  populations  during  a  pandemic.”  Upon 
receipt  of  the  White  House  inquiry,  we  used  our  relationships,  our  team’s  subject  matter 
expertise,  and  our  Lab  sandbox,  to  immediately  spin  up  a  team  of  researchers,  manufacturers, 
governmental  collaborators,  and  FDA/CDRH  leadership  to  rapidly  prototype  EVD  solutions. 
The  demonstrated  use  cases  included  sensor  integration  and  data  acquisition  to  improve 
Ebola  screening,  monitoring  and  diagnosis  in  quarantine,  and  remote  control,  closed  loop 
control,  and  remote  data  access  to  improve  patient  care  and  reduce  the  exposure  of  hospital 
personnel  by  limiting  the  number  of  times  caregivers  enter  the  patient  environment  to  change 
device  settings.  This  was  the  only  known  med-tech  innovation  response  to  EVD  of  its  kind  and 
was  possible  only  due  to  our  existing  collaborative  research  and  Lab  sandbox.  The  teams 
used  our  Medical  Device  Interoperability  Lab  "test  bed"  and  open  platform  for  medical  device 
and  data  integration  -  Open  ICE  -  to  rapidly  prototype  technology  solutions  during  a  three-day 
hackathon  in  November  2016. 

In  addition  to  the  specific  achievements  above,  the  MD  PnP  program  has  continued  to  gain  increasing 
traction  through  our  collaborative  relationships.  The  web  of  connections  among  people  in  our 
community  of  interest  continues  to  generate  new  connections  to  supportive  individuals  in  government 
agencies,  healthcare  institutions,  and  other  organizations  who  are  helping  to  further  the  aims  of  the 
program. 

Synergistic  Activities.  The  activities  under  this  award  have  enabled  the  PI  and  the  MD  PnP  program 
to  remain  actively  involved  with  national  health  IT  developments  to  support  inclusion  of  medical  device 
interoperability  on  the  agenda. 

The  MD  PnP  program  has  continued  to  work  with  the  FDA,  NIST,  NSF,  and  the  Office  of  the  National 
Coordinator  for  Health  IT.  Recognition  of  the  critical  role  of  device  interoperability  in  the  national 
health  IT  agenda  has  increased  greatly,  as  evidenced  by  the  following  activities: 

•  Dr.  Goldman  served  as  invited  co-chair  of  the  Regulations  Subcommittee  of  the  Food  and 
Drug  Administration  Safety  Innovation  Act  (FDASIA)  Workgroup  of  the  Health  IT  Policy 
Committee.  In  the  Subcommittee’s  final  recommendations,  the  importance  of  healthcare  data 
logging  was  cited. 

•  Our  work  under  this  award,  as  well  as  our  larger  body  of  MD  PnP  program  work,  was 
foundational  to  the  new  AAMI/UL  JC2800  device  safety  certification  standard,  which  is  under 
development  with  participation  from  our  team. 

•  The  Data  Logger  work  under  this  award  formed  the  basis  of  an  ICE  Data  Logger  standard 
New  Work  Item  Proposal  to  AAMI  in  2016. 

•  During  the  course  of  this  project.  Dr.  Goldman  continued  to  participate  in  meetings  with  the 
DoD  regarding  procurement  of  medical  devices  -  one  of  the  key  requirements  is  for  devices  in 
future  to  communicate  the  data  needed  for  interoperability. 

Reportable  Outcomes 

Presentations  on  Medical  Device  Interoperability  Topics: 

Dr.  Goldman  delivered  invited  presentations  on  topics  related  to  medical  device  interoperability  for 
improving  patient  safety  and  healthcare  efficiency  to  the  following  groups  during  the  past  year: 

•  September  1 1  2012  at  MDEpiNet  (Medical  Device  Epidemiology  Network)  Annual  Meeting  at 
FDA,  Washington,  DC  (Role  of  ICE  and  Data  Logging  to  support  medical  device  performance 
assessments  for  MDEpiNet) 

•  October  2-3  2012  -  Lectures  and  panel  presentation  at  FDA  AAMI  Interoperability  Summit, 
Washington,  DC 
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•  October  1 5  201 2  -  Panel  moderator  at  American  Society  of  Anesthesiologists  (ASA)  Annual 
Meeting,  Washington,  DC 

•  October  25  201 2  -  Presentation  at  NSF  Time  Workshop,  Baltimore,  MD 

•  November  2  2012  -  Keynote  and  closing  panel  at  Medical  Device  Connectivity  Conference, 
Boston,  MA 

•  November  5  2012  -  Invited  lecture  at  University  of  Illinois  at  Urbana-Champaign,  Urbana,  IL 

•  November  29  201 2  -  Panel  at  Wireless  Connectivity  in  Medical  Devices  Conference,  Boston, 
MA 

•  December  3  2012  -  Panel  moderator  at  FCC  mHealth  Summit,  Washington,  DC 

•  January  10  2013  -  Panel  at  Society  for  Technology  in  Anesthesia  Annual  Meeting,  Phoenix, 
AZ 

•  February  1 6  201 3  -  Panel  at  Advancing  Science,  Serving  Society  Annual  Meeting,  Boston, 

MA 

•  March  4-7  201 3  -  Lecture  and  Technology  Demonstrations  at  HIMSS  Conference,  New 
Orleans,  LA 

•  March  4  2013  -  Keynote  at  IBM  systems  engineering  symposium,  Waltham,  MA 

•  May  20  2013  -  Grand  Rounds  lecture  on  interoperability  at  Tufts  Medical  Center,  Boston  MA 

•  May  23  2013  -  Grand  rounds  lecture  on  interoperability  at  Geisinger  Health  System,  Danville, 
PA 

•  July  3  201 3  -  Lecture  at  meeting  of  Food  and  Drug  Administration  Safety  Innovation  Act 
(FDASIA)  Regulations  Subgroup,  Washington,  DC 

•  September  1 6  201 3  -  Keynote,  “Integrity  of  Medical  Device  Interoperability”  at  AHIMA  Health 
Information  Integrity  Summit,  Alexandria,  VA 

•  September  1 7-1 8  201 3  -  Lecture  and  panel,  “Advanced  Medical  T echnology  T raining  and  the 
APSF  Recommendations:  Perspectives  from  my  Vantage  Point”  at  meeting  of  the  Anesthesia 
Patient  Safety  Foundation,  Phoenix,  AZ 

•  September  24-25  2014  -  MD  PnP  Lab  Open  House  with  technology  demonstrations 

•  October  1 2-1 5  201 3  -  Research  updates  at  annual  ASA  meeting,  to  Scientific  &  Educational 
Exhibits  Committee;  Committee  on  Technology;  Equipment,  Monitoring  &  Engineering 
Technology  Committee;  Equipment  &  Facilities  Committee;  and  Electronic  Media  & 

Information  Technology  Committee,  San  Francisco,  CA 

•  November  1 8-20  201 3  -  Plenary,  “The  SHARP  Program  and  the  Next  Generation  of  Health 
Information  Technology”  at  the  SHARP  ONC  plenary  at  AMIA  Annual  Symposium, 
Washington,  DC 

•  November  21  2013  -  Keynote  “Introduction  to  an  Open-Source  Integrated  Clinical  (ICE) 
Environment  Platform,”  Keynote  Panel  “The  Regulatory  Future  for  Health  IT,  Mobile 
Applications,  and  Interoperability”  and  Plenary  Panel  “Interoperability  Standards:  How  Far  Can 
They  Take  Us?”  at  Medical  Device  Connectivity  Conference,  Herndon,  VA 

•  December  1 2  201 3  -  Presentation  of  Virtual  Hospital  CPS  Testbed  Proposal  at  White  House 
SmartAmerica  CPS  Testbed  Challenge,  Washington,  DC 

•  January  10  2014  -  Panel,  “Interoperability:  A  Cornerstone  of  Systems  Integration”  at  Society  of 
Critical  Care  Medicine  Annual  Congress,  San  Francisco,  CA 

•  January  21-22  2014  -  Chaired  Meetings  for  US  TAG  ISO  TC  121  on  Anesthetic  and 
Respiratory  Equipment  to  lead  the  transition  of  the  US  TAG  from  ASTM  to  AAMI 

•  February  24-26  2014  -  Technology  Demonstration,  “Real-Time  Blue  Button™for  Patients  & 
Families”  in  the  ONC/FHA  area  of  the  HIMSS’14  Interoperability  Showcase,  Orlando,  FL 

•  February  26  201 4  -  Lecture,  “Safe  Interoperability:  What  are  the  Challenges?"  in  the 
HIMSS’14  Interoperability  Showcase  Theater,  Orlando,  FL 

•  April  1  2014  -  Lecture,  “Enabling  Innovation  Through  Medical  Device  Interoperability:  from 
architecture  to  analytics”  at  the  Children’s  Hospital  of  Philadelphia 
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•  April  10  2014  -  Lecture,  “Towards  Better  Critical  Care:  From  data  to  information  to  decision  to 
action”  at  Society  of  Critical  Care  Medicine  Research  Summit,  Emory  Conference  Center, 
Atlanta,  GA 

•  May  14  2014  -  Panels,  “Conformity  assessment  -  Role  in  assuring  safety  and  innovation.”  and 
“Standards  and  Interoperability”  at  NIST/FDASIA  Public  Workshop:  Proposed  Risk-Based 
Regulatory  Framework  and  Strategy  for  Health  Information  Technology,  Washington,  DC 

•  May  15  2014  -  Panel,  “Health  IT  Safety  Center”  at  NIST/FDASIA  Public  Workshop:  Proposed 
Risk-Based  Regulatory  Framework  and  Strategy  for  Health  Information  Technology, 
Washington,  DC 

•  June  10-11  201 4  -  Lecture  and  technology  demonstrations,  “Closed-Loop  Healthcare:  From 
Home  to  Hospital  to  Home”  at  White  House  SmartAmerica  Expo,  Washington,  DC 

•  July  9  2014  -  Congressional  briefing  on  Medical  Device  Inoperability  and  Safe  Medical 
Integration,  Washington,  DC 

•  July  22  2014  -  MD  PnP  Lab  Open  House  with  technology  demonstrations 

•  August  4  2014  -  “Setting  the  Stage  for  the  Next  Generation  of  Clinical  Care  Through  the 
Procurement  of  Interoperable  Medical  Devices  and  Health  IT  Systems,”  AHRRM  Annual 
Conference,  Orlando,  FL 

•  August  16  2014  -  “Interoperability,”  Panel  at  Military  Health  Smart  Monitoring  2014,  Ft 
Lauderdale,  FL 

•  August  19  2014  -  “Web-Based  Clinical  Scenario  Repository™  (CSR™),  Military  Health 
System  Research  Symposium  (MHSRS),  Ft  Lauderdale,  FL 

•  September  10  2014  -  “Challenges:  The  Digital  Health  Platform  (System  of  Systems).”  Panel 
moderator  at  the  National  Academies’  Innovation  Policy  Forum  Workshop  on  Medical  Devices 
Innovation:  Opportunities,  Threats,  and  Challenges,  Washington,  DC 

•  September  29  2014  -  “Remotely  Caring  for  Our  Most  Vulnerable  Citizens  In-Place  During  A 
Pandemic,”  Global  Cities  Challenge:  SMART  America  II,  Washington,  DC 

•  September  30  2014  -  “Overview  of  OpenICE  Federally  funded  open-source  medical  device 
integration,  data  acquisition,  and  app  research  platform  for  use  by  coalition  members,” 

Webinar 

•  October  9  2014  -  “MD  PnP  Program  Updates”  at  University  of  Pennsylvania  PRECISE  Center, 
Philadelphia,  PA 

•  October  11-14  2014  -  Updates  on  MD  PnP  research  to  several  committees  at  ASA  Annual 
Meeting,  New  Orleans,  LA 

•  October  20  2014  -  “Medical  Device  Interoperability,”  Congressional  Staff  Briefing, 
Washington,  DC 

•  October  22  2014  -  MD  PnP  Research  Demonstrations  at  Lab  Open  House,  Cambridge  MA 

•  November  4-6  2014  -  “Open  Medical  Device  and  Data  Integration  Platforms  to  support  the 
management  of  Ebola,”  presentations  to  press  and  lab  visitors,  Cambridge  MA 

•  November  20  2014  -  “A  Systems  Oriented  Approach  to  Optimize  the  Performance  of  Clinical 
Alarms,”  keynote  address  at  Clinical  Alarms  Safety  Symposium,  Washington,  DC 

•  November  21  2014  -  Grand  Rounds  at  San  Diego  Naval  Hospital,  San  Diego,  CA 

•  December  6-7  2014  -  “Technology  Advancements  in  the  Intelligent  Medical  Home:  From  the 
Leaders  Perspective,”  keynote  and  panel  at  mHealth  Symposium,  Washington  DC 

•  December  8  2014  -  “Open  Medical  Device  and  Data  Integration  Platforms  to  support  the 
management  of  Ebola,”  White  House  briefing,  Washington,  DC 

•  December  1 6  201 4  -  “Overview  of  MGH  MD  PnP  Program  /  MD  PnP,”  Georgetown  University 
Visiting  Scholars  presentations,  Massachusetts  General  Hospital,  Cambridge,  MA 

•  January  8  201 5  -  “Innovations  in  Standards  for  Interoperability,”  STA  Annual  Meeting, 

Phoenix,  AZ 

•  January  21  2015  -  “Answering  the  White  House’s  call  to  innovate  safer  ways  to  treat  Ebola 
patients”  /  Invited  Lecture  Newton  Inspires,  Newton,  MA 
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•  January  28  2015  -  “Integrated  Healthcare  Platforms  to  Enable  Safety,  Security,  and 
Interoperability,”  Indian  Institute  of  Technology,  Chennai,  India 

•  February  1 3  201 5  -  “Open  Medical  Device  and  Data  Integration  Platforms  to  Support  the 
Management  of  Ebola  Care,”  Webinar 

•  February  1 9  201 5  -  “Achieving  Interoperability  in  Medical  Device  T echnology  to  Support 
Innovation”  /  Panelist  Medical  Devices  Summit,  Boston,  MA 

•  February  24  201 5  -  “Medical  Device  and  Data  Integration  Platforms  to  Support  the 
Management  of  Ebola,”  NIST  Testbed  Workshop,  Rockville,  MD 

•  February  24-25  201 5  -  Panel  at  Agency  for  Healthcare  Research  and  Quality  (AHRQ) 
Headquarters,  Rockville,  MD 

•  February-March  2015  -  “Overview  of  MGH  MD  PnP  Program,”  lectures  for  Boston  University, 
Bentley  University,  and  Georgetown  University  graduate  students,  MD  PnP  Visiting  Scholars 
presentations,  Cambridge,  MA 

•  March  17  2015  -  “Medical  Device  Interoperability  Roadmap”  lecture  at  Interoperability 
Advisory  Group  meeting,  Washington  DC 

•  March  25  2015  -  Keynote  and  panel  at  Object  Management  Group  Conference,  Washington 
DC 

•  March  25  2015  -  “Open  Sourced  Technology  Advancements  in  Medical  IIC,”  invited  lecture  at 
Industrial  Internet  Consortium  meeting,  Washington  DC 

•  March  26  2015  -  “Medical  Device  Interoperability”  /  Grand  Rounds  Hershey  Medical  Center, 
Hershey  PA 

•  December  24  201 5  -  “Medical  Internet  of  Things  (MIoT)”  /  Grand  Rounds  Department  of 
Anesthesia,  Critical  Care,  and  Pain  Medicine,  Massachusetts  General  Hospital,  Boston,  MA 

•  April  15  201 5 -“Introduction  to  The  ICE  Alliance,”  HIMSS15,  Chicago,  IL 

•  April  13-16  2015  -  “Auto-Validation  of  Medical  Device  for  EMR  Data  Entry,”  presentations  and 
demonstrations  at  HIMSS15,  Chicago,  IL 

•  April  17  2015  -  “Open  Medical  Device  and  Data  Integration  Platform  for  Medical  loT,” 
Conference  of  loT  in  Healthcare,  Costa  Rica 

•  April  27  2015  -  “Technology  Advancements  in  Medical  Interoperability,”  UL  Health  Sciences 
Council,  Chicago,  IL 

•  June  4  2015  -  “Auto-Validation  of  Medical  Device  for  EMR  Data  Entry,”  presentations  and 
demonstrations  at  AAMI  Expo,  Denver,  CO 

•  June  10  2015  -  “Innovations  in  Standards  for  Interoperability,”  presentation  and  panel  at 
AAMI  Standards  week,  Denver,  CO 

•  August  15-16  2015  -  Participated  in  FDA  panel  and  presented  “Ebola  Care  Medical- 
Technology  Response:  Open  Medical  Device  &  Data  Integration  Platforms  to  Support 
Management  of  Ebola  Virus  Disease,”  Smart  Monitoring  Conference,  Ft  Lauderdale,  FL 

•  August  1 9  201 5  -  “Autovalidation  of  Medical  Device  Data  for  EHRs  Using  Apps  on  an  Open 
Medical  Device  Integration  Platform  (ICE  Platform),”  Military  Health  System  Research 
Symposium  Training  &  Informatics  session  (MHSRS-15-1 192),  Ft  Lauderdale,  FL 

•  Sept  1 8  201 5  -  “Remote  Caring  for  Vulnerable  Population  during  a  Pandemic:  Demonstrating 
the  Vision  of  the  Medical  Internet  of  Things,”  Internet  of  Things  Solutions  World  Congress, 
Barcelona 

•  September  30  2015  -  Presentation  at  Cybersecurity  for  Healthcare  and  Medical  Devices 
conference,  Minneapolis  ,  MN 

•  October  24-28  2015  -  American  Society  of  Anesthesiologists,  presentations  at  MD  PnP 
Exhibit  (1®’  Place  Award),  San  Diego,  CA 

•  February  8  2016  -  Presentation  at  Boston  Medical  Devices  Summit,  Boston,  MA 

•  March  2  2016  -  Presentation  at  HIMSS  Conference,  “Advancing  Health  Equity  through 
Precision  Medicine  and  HIT  Innovation,”  Las  Vegas,  NV 

•  April  6  2016  -  Presentation  at  HxR  Conference,  Boston,  MA 
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•  April  27  201 6  -  Presentation  at  AAMI  OR  Systems  Engineering  Conference,  Washington,  DC 

•  May  6  2016  -  Invited  Speaker  for  Grand  Rounds,  “The  Medical  Internet  of  Things,”  Tufts 
Medical  Center,  Boston,  MA 

•  June  28  2016  -  Keynote  Lecture,  “Implementing  the  Medical  Internet  of  Things  (MIoT)  to 
Enable  Healthcare  Transformations,”  Council  of  Engineering  Systems  Universities  (CESUN), 
Washington  DC 

•  August  15  2016  -  Invited  Speaker,  “Integrating  Medical  Devices  -  Better  Clinical  Decisions  - 
Efficient  &  Controlled  Patient  Care,”  MSRS,  Ft  Lauderdale,  FL 

•  August  19  2016  -  MD  PnP  Poster  Presentation  at  IEEE  EMBS  Annual  Conference,  Orlando, 
FL 

•  September  13  2016  -  JPC-1  Medical  Simulation  &  Information  Sciences  Internal  Project 
Review,  Ft  Detrick,  MD 

Presentations  on  behalf  of  the  PI: 

•  December  6  2013  -  Technology  demonstration  at  FCC  mHealth  Innovation  Expo  by  David 
Arney  and  Jeff  Plourde,  Washington,  DC 

•  April  2  2014  -  Poster  presentation  on  “Web-Based  Clinical  Scenario  Repository  to  Improve 
Patient  Safety”  at  Mass  General  Hospital  Scientific  Advisory  Council  poster  sessions  by  Diego 
Alonso 

•  April  14  2014  -  “Design  Pillars  for  Medical  Cyber-Physical  System  Middleware"  by  David 
Arney  and  Jeff  Plourde  at  Medical  CPS  Workshop,  Berlin,  Germany 

•  April  14  2014  -  Poster  presentation  on  "Potential  Advantages  of  Applying  Assurance  Case 
Modeling  to  Requirements  Engineering  for  Interoperable  Medical  Device  Systems”  by  David 
Arney  and  Jeff  Plourde  at  Medical  CPS  Workshop,  Berlin,  Germany 

•  April  1 6  201 4  -  Poster  and  Work  in  Progress  talk  on  "OpenICE:  An  Open,  Interoperable 
Platform  for  Medical  Cyber-Physical  Systems”  by  David  Arney  and  Jeff  Plourde  at  the 
International  Conference  on  Cyber-Physical  Systems  (ICCPS),  Berlin,  Germany 

•  August  19,  2014  -  Poster  Presentation  on  “OpenICE  Prototype:  A  New,  Open  Interoperable 
Medical  Device  Clinical  Research  Platform”  by  Jeff  Plourde,  Military  Health  System  Research 
Symposium  (MHSRS),  Ft  Lauderdale,  FL 

•  November  5-6  2014  -  “Open  Sourced  Interoperability,”  by  Jeff  Peterson,  Northeastern 
Healthcare  Technology  Symposium,  Groton,  CT 

•  December  16  2014  -  “Open  Source  Interoperability:  A  Technical  Review  of  OpenICE  and 
DDS,”  by  Jeff  Peterson,  Georgetown  University  MD  PnP  Visiting  Scholars  presentations, 
Cambridge,  MA 

•  February  12  2015  -  “Open  Source  Interoperability  -  Intro  to  OpenICE,”  by  Jeff  Peterson, 
Educational  Webinar  session.  Innovators  Showcase:  Three  Clinical  Engineers  Leading  the 
Way,  Cambridge,  MA 

•  February  26  2015  -  “Healthcare  loT:  The  Impact  in  the  Hospital,”  by  David  Arney,  MIT 
Connected  Things  Forum,  Cambridge,  MA 

•  March  23  2015  -  “Requirements  Management  for  Open  Source  Interoperability”  by  Harshal 
Sawant  at  the  Serena  Conference,  Washington  DC 

•  June  4-7  2015  -  “Auto-Validation  of  Medical  Device  for  EMR  Data  Entry”  presentations  and 
demonstrations  by  David  Arney  and  Jeff  Peterson  at  AAMI  Expo,  Denver,  CO 

•  June  8  2015  -  Presentation  by  Harshal  Sawant  at  AAMI  Standards  Week,  Denver,  CO 

•  October  13-14  2015  -“Software  Implementation  of  Controllers:  Hardware  considerations  for 
sensors  and  actuators”  by  David  Arney  at  FDA  PCLC  workshop.  Silver  Spring,  MD 

•  October  15  2015  -  “The  Internet  of  Things’  and  Its  Impact  on  Software  Development  for 
Medical  Devices”  by  David  Arney  at  Software  Design  for  Medical  Devices  2015,  Boston,  MA 
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•  October  14  2015  -  OpenICE  Workshop  at  AMIA  Transdisciplinary  “Maker  Health  Faire,”  by 
David  Arney  at  American  Medical  Informatics  Association  annual  conference,  San  Francisco, 
CA  (https://www.amia.orq/amia2015/tutorials) 

•  February  8  2016  -  “Medical  Device  Interoperability  and  Cybersecurity”  by  David  Arney  at 
Cybersecurity  Workshop,  Medical  Devices  Summit,  Boston,  MA 

•  March  20-23  2016  -  “Securing  Medical  Cyber-Systems:  Challenges  and  Future  Directions”  by 
David  Arney  at  ISMICT  2016,  Worcester  Polytechnic  Institute,  Worcester,  MA 
(http://www.cwins.wpi.edu/ismict16/) 


Web  Site: 

•  www.mdpnp.orq  is  maintained  as  a  major  communication  vehicle  for  the  program.  The  website 
provides  access  to  the  ICE  standard,  MD  FIRE  contracting  language,  publications,  posters, 
talks  from  plenary  meetings  and  from  the  FDA  Workshop,  and  downloads  of  sharable 
documents  and  code  from  our  GitHub  public  project  via  www.OpenlCE.info. 
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•  Arney  D,  Plourde  J,  Schrenker  R,  Mattegunta  P,  Whitehead  SF,  Goldman  JM.  Design  Pillars 
for  Medical  Cyber-Physical  System  Middleware.  In:  OpenAccess  Series  in  Informatics 
(OASIcs);2014;  36. 

•  Schrenker  Rick,  Plourde  J,  Alonso  D,  Arney  D,  Goldman  JM.  Potential  Advantages  of 
Applying  Assurance  Case  Modeling  to  Requirements  Engineering  for  Interoperable  Medical 
Device  Systems.  In:  OpenAccess  Series  in  Informatics  (OASIcs);  2014;  141. 

•  Wu  PL,  Raguraman  D,  Sha  L,  Berlin  RB,  Goldman  JM.  WiP  abstract:  A  treatment 
coordination  protocol  for  cyber-physical-human  medical  systems.  In:  Cyber-Physical  Systems 
(ICCPS);  2014:  226. 

•  Plourde  J,  Arney  D,  Goldman  JM.  OpenICE:  An  open,  interoperable  platform  for  medical 
cyber-physical  systems.  In:  Cyber-Physical  Systems  (ICCPS);  2014:  221. 


May  2017 


52 


•  Goldman  JM.  The  Challenge  of  Acquiring  Accurate,  Complete,  Near-Patient  Clinical  Data  for 
Data  Science  Analysis.  In:  NIST  Data  Science  Symposium  Proceedings,  March  4-5  2014, 
Gaithersburg,  MD;  2014.  p.  43-44. 

•  Kang  W,  Sha  Lui,  Berlin  RB,  Goldman  JM.  The  design  of  safe  networked  supervisory  medical 
systems  using  organ-centric  hierarchical  control  architecture.  In:  IEEE  Journal  of  Biomedical 
and  Health  Informatics.  2014;  19:  1077-1086. 

•  Wu  Po-Liang,  Raguraman  D,  Sha  Lui,  Berlin  RB,  Goldman  JM.  A  treatment  validation 
protocol  for  cyber-physical-human  medical  systems.  In:  2014  40th  EUROMICRO  Conference 
on  Software  Engineering  and  Advanced  Applications;  2014:  183-190. 

•  Rahmaniheris  M,  Sha  L,  Berlin  RB,  Goldman  JM.  Towards  a  cyber-medical  model  for  device 
configuration  safety  in  acute  care.  In:  Healthcare  Innovation  Conference  (HIC),  2014:  118-124. 

•  Goldman  JM.  Solving  the  interoperability  challenge:  safe  and  reliable  information  exchange 
requires  more  from  product  designers.  IEEE  Pulse.  2014  Nov-Dec;5(6):37-9.  doi: 
10.11 09/MPUL.201 4.2355307 

•  Weininger  S,  Jaffe  MB,  Rausch  T,  Goldman  JM.  Capturing  Essential  Information  to  Achieve 
Safe  Interoperability.  Anesth  AnaIg  2017;124:83-94. 

•  Dain  S,  Rausch  T,  Goldman  JM.  Domain  Information  Model  for  Alarm  Systems  for  the  Patient 
Centric  Integrated  Clinical  Environment  (ICE  DIM).  In:  Anesth  AnaIg;  2016;  122. 

•  Goldman  JM.  Leadership  and  Vigilance  Essential  as  Health  Information  Technology  Expands. 
In:  ASA  Monitor;  2016;  80:  18-19. 

•  Weininger  S,  Jaffe  MB,  Robkin  M,  Rausch  T,  Arney  D,  Goldman  JM,  The  Importance  of  State 
and  Context  in  Safe  Interoperable  Medical  Systems.  IEEE  J  TransI  Health  Med  2016;  99: 
2168-2372.  4:2800110. 

•  Weininger  S,  Jaffe  MB,  Goldman  JM.  The  Need  to  Apply  Medical  Device  Informatics  in 
Developing  Standards  for  Safe  Interoperable  Medical  Systems.  Anesth  AnaIg  2017;  124:127- 
135. 

Funding  Applications  Facilitated  by  this  BAA  to  Date  (total  costs  shown): 

•  W81XWH-15-C-0064- 2015-2016 
1-Year  award  for  $453,799  Total 

Description:  Building  on  our  prototype  open  platform  for  integrating  devices  in  the  clinical 
environment  ("Open ICE")  to  provide  re-configurable  COTS-based  clinical  monitoring  and 
decision  support  capability  to  improve  the  efficiency  and  effectiveness  of  the  monitoring  and 
evaluation  of  patients  in  forward  holding  areas,  with  a  focus  on  monitoring  patients  with  illness 
related  to  heat  stress. 

•  BAA  for  Joint  Warfighter  II  -  recommended  for  award  August  201 6  but  funding  pending 
4-Year  award  for  $5,823,887  Total 

Description: 

1 .  Develop  Real  Time  CDS  apps  as  described  above  (apps  that  will  be  useful  in  their  own 
right),  and  define  the  ICE  platform,  device  interoperability,  and  cybersecurity  capabilities 
that  are  necessary  for  broad  commercial  development  and  adoption  of  advanced  app 
capabilities  that  will  rely  on  networked  medical  devices. 

2.  Define  a  testing  methodology  and  certification  program  to  allow  medical  device 
manufacturers  to  demonstrate  that  their  products  acceptably  conform  to  interoperability 
standards  and  mitigate  known  cybersecurity  threats. 

3.  Define  medical  device  interoperability  success  metrics  and  applicable  standards;  work  with 
the  broader  community  to  build  a  consensus  on  hazard  analysis,  standards,  and  mitigation 
for  cybersecurity-related  threats. 
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4.  Implement  in  our  Lab  a  test  and  certification  program  whereby  manufacturers  can  have 
their  devices  tested  and  certified. 

5.  Together  with  CIMIT,  focus  throughout  this  research  project  on  development  of  a  business 
and  commercialization  plan. 

Conclusions 

There  is  increasing  recognition  that  interoperable  medical  device  and  Health  IT  systems  are  needed 
for  healthcare  delivery.  Platforms  such  as  ICE,  including  reference  implementations  of  standards  and 
architectures,  are  needed  for  the  adoption  of  interoperability.  These  capabilities  must  be  fully  and 
freely  available  to  the  community  of  hospitals,  manufacturers,  standards  developers,  computer 
science  and  engineering  students,  app  developers,  regulators,  and  everyone  else  who  is  eager  to 
work  together  to  mature  the  healthcare  technology  ecosystem  to  enable  the  next  generation  of  safe 
and  intelligent  medical  device  and  HIT  systems. 

ICE  Data  Logging:  The  ICE  Data  Logger  is  an  essential  component  of  the  ICE  platform.  With  the 
exception  of  clinical  care  settings,  safety  critical  environments  like  aircraft  have  “black  box  recorder” 
forensic  data  loggers.  The  inability  to  create  a  synchronized,  reliable  log  of  data  communicated  to  and 
from  all  connected  medical  devices  used  in  the  treatment  of  a  patient  has  served  as  a  barrier  to 
quality  improvement  initiatives  such  as  after-action  reports  for  medical  device-related  and  network 
performance  issues.  Furthermore,  liability  and  safety  concerns  related  to  networked  medical  device 
systems  -  especially  the  use  of  new  devices  and  apps  to  enable  innovation  -  cannot  be  effectively 
addressed  without  a  forensic  data  log  to  identify  whether,  for  example,  an  app,  sensor,  operator,  or 
malware  contributed  to  an  action,  and  the  resultant  outcome.  Finally,  ICE  data  logging  will  help  drive 
improvements  in  medical  device  interoperability  and  cybersecurity  -  data  must  be  communicated  to 
the  data  logger  to  be  logged,  and  the  data  logs  are  necessary  to  analyze  the  effects  of  cybersecurity 
exploits. 

The  clinical  and  business  rationales,  technical  and  standards  pathways,  and  community  acceptance 
for  ICE  Data  Logging,  have  all  been  facilitated  by  research  funded  under  this  award  as  described  in 
detail  above.  A  key  accomplishment  was  the  drafting  of  a  35-page  proposed  draft  standard  for: 

Requirements  for  the  forensic  (biack  box)  data  iogger  for  an  integrated  ciinicai  environment 
(ICE)  or  Medical  devices  and  medical  systems  —  Basic  safety  and  essential  performance  of 
the  patient-centric  integrated  clinical  environment  (ICE)  —  Partx:  Particular  requirements  for 
the  forensic  (black  box)  data  logger 

The  draft  was  based  primarily  on  research  performed  under  Aim  1  (ICE  Data  Logger),  but  it  was 
informed  by  research  performed  under  Aim  4  (ICE  External  Interface  Data  Transfer)  with  community 
support  strengthened  by  Aim  2  (Web-Based  Clinical  Scenario  Repository)  and  Aim  3  (Open  Source 
Code  Dissemination).  Due  to  the  extensive  research  performed  under  this  award,  the  draft  standard  is 
ready  for  submission  to  AAMI  for  consideration  as  a  new  standard  under  the  AAMI  Interoperability 
Working  Group. 

Clinical  Scenario  Repository™:  When  our  MD  PnP  program  embarked  on  enabling  and  promoting 
medical  device  interoperability  to  improve  patient  safety  and  healthcare  outcomes,  we  convened 
several  workshops  to  identify  historical  interoperability  barriers  and  define  a  pathway  for  success.  One 
of  the  identified  barriers  was  the  disconnect  between  clinical  needs,  commercial  solutions,  and 
medical  device/HIT  standards  that  manufacturers  use.  In  a  small  pilot  project  we  learned  that  each 
manufacturer  and  almost  every  standards  committee  attempt  to  identify  clinical  user  needs  on  their 
own,  but  there  were  no  common  tools,  methods,  or  information  sharing,  and  no  pathway  for  customer- 
initiated  descriptions  of  scenarios  in  which  interoperability  could  improve  specific  workflows  or  reduce 
specific  patient  risks. 
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The  CSR™  is  intended  to  enable  the  voice  of  the  customer  to  be  captured  to  guide  the  development 
of  standards  and  technologies.  It  differs  from  conventional  "safety  reports"  that  are  based  on 
mandatory  reporting  of  adverse  events.  The  CSR™  is  intended  to  contain  clinical  scenarios  or  "good 
ideas"  that  if  implemented,  could  improve  safety,  improve  workflow,  and  facilitate  innovation.  These 
scenarios  can  serve  as  design  inputs  for  a  system  of  standards  and  technology  development,  and 
help  ensure  that  interoperability  solutions  are  clinically  driven.  It  could  become  a  core  means  by  which 
the  clinical  user  community  can  clarify  expectations  of  new  technologies  and  integrated  medical 
device-HIT  system  capabilities  for  use  by  developers,  regulators,  researchers,  and  equipment 
procurers. 

Through  this  award  we  refined  the  interoperability  ecosystem  gaps  that  the  CSR™  could  improve, 
researched  data  entry  methods  and  templates,  iterated  deployment  platforms,  identified  essential 
governance  requirements,  socialized  prototypes  with  standards  development  committees  to  ensure 
the  CSR™  output  will  be  useful  to  align  standards,  and  performed  pilots  with  clinicians  to  refine  the 
prototypes  and  acquire  useful  scenarios. 

While  demonstrating  the  CSR™  to  clinicians  and  hospital  risk-management  professionals,  we  found 
that  it  was  a  tool  they  didn’t  know  they  needed,  but  now  they  wish  they  had.  Clinicians  are  familiar 
with  mandatory  reporting  systems  that  are  used  to  report  adverse  events  -  not  to  capture  general 
experiences  with  technology  or  “good  ideas”  for  innovative  interoperable  products.  As  a  result  of 
performing  this  research  and  communicating  the  research  findings,  a  strong  healthcare  delivery 
organizational  (market)  interest  in  adopting  data  logging  and  implementing  CSR™  tools  has  been 
cultivated. 

Code  Sharing,  ICE  External  Interface,  and  Demonstrations:  As  the  report  describes,  this  research 
award  enabled  our  team  to  engage  in  numerous  activities  to  disseminate  research  results,  share 
diverse  technical  and  clinical  insights  on  the  pathway,  benefits,  and  challenges  of  enabling  medical 
device  interoperability  for  Integrated  Clinical  Environments. 

The  progression  of  medical  device  interoperability  -  especially  ICE  -  in  medical  device,  HIT,  and 
cybersecurity  standards,  clinical  and  hospital  interest  in  CSR™  reporting  paradigms,  and  ICE 
implementations  of  commercial  interest,  have  been  spurred  by  the  research  supported  by  this  grant. 
The  exhibits  and  demonstrations  at  HIMSS  and  other  venues  have  provided  governmental  and 
commercial  leaders  with  a  view  of  the  healthcare  benefits  that  can  be  accomplished  as  we  identify 
technical  and  administrative  means  to  share  information  and  integrate  medical  equipment  and  Health 
IT  systems  into  ICE  systems.  Moreover,  the  demonstrations  and  shared  software  code  have  lowered 
the  barrier  for  others  to  leverage  our  research  and  prove  that  the  proposed  innovations  are 
achievable. 
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Error!  Reference  source  not  found. 


IMPORTANT: 


Background  and  attribution: 

This  document  was  drafted  by  the  Massachusetts  General  Hospital  MD  PnP  Research 
Program''  during  2014-2016,  with  support  by  the  DOD^  for  the  preparation  of  a  standard  for 
the  ICE  Data  Logger  in  alignment  with  requirements  in  ASTM  F2761-09(13).  The  proposed 
standard  is  based  on  research  conducted  in  part  under  DOD,  NIH^,  and  NIST  grant  funding 
performed  by  the  MD  PnP  and  collaborators  in  industry  and  academia. 

This  document  has  been  reviewed,  edited,  and  approved  by  the  AAMI  SM  WG03  Committee 
2016-06-07  to  provide  content  in  support  of  an  AAMI  NWIP  for  an  ICE  Data  Logger  standard. 

The  document  is  based  on  an  ISO  template  for  convenience.  It  is  anticipated  to 
require  revision  if  published  by  another  SDO. 

Error!  Reference  source  not  found. 

(This  is  an  ISO  format  template,  for  convenience)  Error!  Reference  source  not  found. 
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Foreword  (this  text  is  from  an  iSO  tempiate  -  but  the  document  may  be 
submitted  to  an  SDO  other  than  iSO) 

ISO  (the  International  Organization  for  Standardization)  is  a  worldwide  federation  of  national  standards  bodies 
(ISO  member  bodies).  The  work  of  preparing  International  Standards  is  normally  carried  out  through  ISO 
technical  committees.  Each  member  body  interested  in  a  subject  for  which  a  technical  committee  has  been 
established  has  the  right  to  be  represented  on  that  committee.  International  organizations,  governmental  and 
non-governmental,  in  liaison  with  ISO,  also  take  part  in  the  work.  ISO  collaborates  closely  with  the 
International  Electrotechnical  Commission  (lEC)  on  all  matters  of  electrotechnical  standardization. 

International  Standards  are  drafted  in  accordance  with  the  rules  given  in  the  ISO/IEC  Directives,  Part  2. 

The  main  task  of  technical  committees  is  to  prepare  International  Standards.  Draft  International  Standards 
adopted  by  the  technical  committees  are  circulated  to  the  member  bodies  for  voting.  Publication  as  an 
International  Standard  requires  approval  by  at  least  75  %  of  the  member  bodies  casting  a  vote. 

Attention  is  drawn  to  the  possibility  that  some  of  the  elements  of  this  document  may  be  the  subject  of  patent 
rights.  [“ISO”]  The  authors  and  the  SDO  shall  not  be  held  responsible  for  identifying  any  or  all  such  patent 
rights. 

This  is  the  first  edition. 

This  work  is  based  in  part  on  research  and  concepts  developed  within  the  program  on  Medical  Device  “Plug- 
and-Play”  Interoperability  (“MD  PnP”  program,  founded  2004),  enriched  and  disseminated  through 
publications,  workshops,  and  website,  funded  in  part  by  US  Federal  Grants  and  contracts.  MD  PnP  is  a 
research  program  founded  by  Julian  M.  Goldman,  MD,  based  at  the  Massachusetts  General  Hospital  and 
affiliated  with  CIMIT,  Partners  Healthcare,  and  Harvard  Medical  School.  ICE  data  logging  concepts  contained 
in  this  document  are  based  in  part  on  a  research  collaboration  with  NIST. 

The  MD  PnP  program  and  academic  and  manufacturer  collaborators  have  developed  an  extensive  body  of 
scientific  and  technical  knowledge,  much  of  which  has  been  placed  in  the  public  domain  to  accelerate  the 
development  of  platforms  for  Integrated  Clinical  Environments  to  improve  the  quality,  safety,  and  value  of 
healthcare  delivery. 

The  intellectual  property  provided  as  the  basis  for  this  standard  shall  remain  with  the  developer  or  owners  of 

the  intellectual  property,  and  is  not  intended  to  become  exclusively  the  rights  of  any  SDO-XXX,  inclusing  the 

SDO  publishing  this  international  standard,  [section  removed  as  required  by  AAMI  SB] 

The  “ICE”  family  of  standards  has  been  proposed  in  ASTM  F2761  -09  (“Part  1  ”)  to  consist  of  the  following  parts, 
under  the  general  title  Medical  devices  and  medical  systems  —  Basic  safety  and  essential  performance  of  the 
patient-centric  integrated  clinical  network  environment  (ICE) 

—  Part  1:  General  requirements  and  conceptual  model,  published  as  ASTM  F2761-09  (13) 

—  Part  2:  Requirements  for  network  control  and  equipment  interface 

—  Part  3:  Requirements  for  device  models 

—  Part  4:  Requirements  for  supervision 

—  Part  5:  Requirements  for  safe  and  reliable  integration 

—  Part  6:  Particular  requirements  for  the  forensic  data  logger  -  This  standard 
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In  this  Standard,  the  following  print  types  are  used: 

-  Requirements  and  definitions:  roman  type. 

-  Test  specifications:  itaiic  type. 

-  Informative  material  appearing  outside  of  tables,  such  as  notes,  examples  and  references:  in  smaller  type.  Normative 
text  of  tables  is  also  in  a  smaller  type. 

T ERMS  DEFINED  IN  THIS  STANDARD  OR  AS  NOTED:  SMALL  CAPITALS  TYPE. 

In  this  standard,  the  conjunctive  “or”  is  used  as  an  “inclusive  or”  so  a  statement  is  true  if  any  combination  of 
the  conditions  is  true. 

The  verbal  forms  used  in  this  standard  conform  to  usage  described  in  Annex  H  of  the  ISO/IEC  Directives,  Part 
2.  For  the  purposes  of  this  standard,  the  auxiliary  verb: 

-  “shall”  means  that  compliance  with  a  requirement  or  a  test  is  mandatory  for  compliance  with  this 
standard; 

-  “should”  means  that  compliance  with  a  requirement  or  a  test  is  recommended  but  is  not  mandatory  for 
compliance  with  this  standard; 

-  “may”  is  used  to  describe  a  permissible  way  to  achieve  compliance  with  a  requirement  or  test. 

Clauses,  subclauses  and  definitions  for  which  a  rationale  is  provided  in  informative  Annex  A  are  marked  with 
an  asterisk  (*). 

The  committee  has  decided  that  the  contents  of  this  amendment  and  the  base  publication  will  remain 
unchanged  until  the  maintenance  result  date)  indicated  on  the  lEC  web  site  under  ''http://webstore.iec.ch''  in 
the  data  related  to  the  specific  publication.  At  this  date,  the  publication  will  be 

-  reconfirmed; 

-  withdrawn; 

-  replaced  by  a  revised  edition;  or 

-  amended 

The  attention  of  Member  Bodies  t‘member  bodies”  is  an  ISO  and  lEC  term|)  is  drawn  to  the  fact  that 
equipment  manufacturers  and  testing  organizations  may  need  a  transitional  period  following  publication  of  a 
new,  amended  or  revised  [insert  SDO  name  here]  (may  state  “ISO”)  publication  in  which  to  make  products  in 
accordance  with  the  new  requirements  and  to  equip  themselves  for  conducting  new  or  revised  tests.  It  is  the 
recommendation  of  the  committee  that  the  content  of  this  publication  not  be  adopted  for  mandatory 

implementation  nationally  earlier  than  3  years  from  the  date  of  publication  for  equipment  newly  designed  and 

not  earlier  than  5  years  from  the  date  of  publication  for  equipment  already  in  production. 
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Introduction 

Medical  devices  are  essential  for  the  practice  of  modern  medicine.  The  capability  of  logging  of  data  from 
individual  Medical  devices  and  single  manufacturer  multi-parameter  monitoring  devices  is  well  known.  This 
capability  is  available  to  varying  degrees  [needs  explanation  in  rationale].  Medical  devices  have  had  some 
data  logging  capabilities  for  several  decades.  The  device-level  data  store  (or  Data  Log)  is  not  standardized 
as  to  content  or  format  and  may  include  proprietary  device  performance  metrics  for  technical  troubleshooting 
and  maintenance,  and  clinical  data  for  patient  care.  These  logs  are  acquired  when  performing  adverse  event 
analysis,  but  even  if  one  device  log  is  fairly  “complete”,  a  log  of  the  entire  clinical  picture  including  data  from 
the  system  of  all  devices  in  use  at  that  time,  is  not  available.  For  example,  in  typical  complex  clinical 
environments  (e.g.  OR,  ICU,  ED)  the  time-aligned  integration  of  data  streams  from  multiple  devices  -  each 
with  its  own  proprietary  communication  protocols  and  algorithms,  time  base,  and  physical  interfaces  -  offers 
numerous  challenges.  An  integrated  data  logging  capability  is  needed  for  the  entire  clinical  environment  in 
which  the  patient  is  being  monitored  or  is  receiving  therapy  -  to  include  logging  of  network-communicated 
commands,  user  interaction  with  devices  -  such  as  key  presses,  device  connection  and  disconnection, 
physiologic  and  technical  alarms,  patient  physiologic  data,  and  other  device  status  information. 

The  Integrated  Clinical  Environment  (ICE)  Standard,  ASTM  F2761-09(13),  Part  1  of  this  standard  series, 
established  the  general  principles  for  the  design,  verification,  and  validation  of  a  model-based  integration 
system  that  enables  the  creation  of  an  integrated  clinical  environment  intended  to  facilitate  cross- 
MANUFACTURER  MEDICAL  DEVICE  interoperability  (heterogeneous  interoperability).  Part  2  of  this  series  focuses 
on  the  requirements  of  ICE  data  logger.  Regulatory  and  clinical  needs,  particularly  with  respect  to  adverse 
EVENT  and  incident  reporting  and  investigation  [insert  notion  of  time-synchronized  log  and  notion  of  regulated 
and  non-regulated  equipment  used  for  clinical  care],  are  influencing  the  development  of  this  ICE  system  data 
logging  standard,  also  known  as  the  ICE  data  logger.  It  is  easily  imagined  that  with  the  widespread 
availability  of  an  integrated  forensic  data  store,  opportunities  for  new  and  improved  capabilities  for  forensic 
data  analysis,  post  and  real-time  clinical  analytics,  quality  assurance,  and  healthcare  delivery  organization  and 
clinician  credentialing  will  emerge.  Other  parts  of  this  standard  series  are  intended  to  focus  on  communication 
of  PATIENT  data  and  on  equipment  command  and  control,  as  well  as  on  the  functionality  necessary  for  the 
seamless  creation  of  an  integrated  clinical  environment. 

The  approach  defined  and  described  by  this  series  of  standards  for  the  integrated  clinical  environment 
(ice)  includes  provisions  for  error  resistance,  and  continual  improvements  in  patient  safety,  treatment  efficacy 
and  workflow  efficiency  based  on  device  interoperability  and  safe  system  integration. 
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2  1  Scope 

3  This  standard  specifies  general  requirements,  a  model  and  framework  for  a  (forensic)  data  logger,  the  ICE 

4  DATA  LOGGER,  a  component  of  the  integrated  clinical  environment. 

5  This  standard  is  intended  to  define  the  requirements  essential  for  safety  and  thereby  facilitate  regulatory 

6  acceptance. 

7  This  standard  provides  requirements  for  system  data  logging  capabilities  in  support  of  forensic  analysis  of  ICE  systems. 

8  Data  logs,  data  logging,  and  data  loggers  play  important  roles  in  the  basic  safety  and  essential  performance  of  integrated 

9  clinical  environments.  This  standard  is  intended  to  provide  additional  requirements  for  users  and  manufacturers  of  a  data 

10  logger  as  described  in  ASTM  F2761 -09(201 3),  subclause  4.2.4,  Medical  Devices  and  Medical  Systems  -  Essential  safety 

11  requirements  for  equipment  comprising  the  patient-centric  integrated  clinical  environment  (ICE)  -  Part  1:  General 

12  requirements  and  conceptual  model  (i.e.  ICE  standard). 

1 3  This  standard  specifies  general  functional  and  interoperability  requirements,  a  model  and  a  framework  for  a  data  logger 

14  which  is  a  component  in  an  integrated  clinical  environment.  The  standard  will  identify  use  cases  for  the  types  of  data  to  be 

15  collected. 

1 6  Note:  This  type  of  data  logger  is  also  referred  to  as  a  “black  box  recorder”  in  other  sectors. 

17  Note:  The  development  activities  of  this  standard  are  intended  to  align  with  related  content  in  ASTM  F2761 -09(201 3)  and 

18  its  successors,  be  complementary  with  related  AAMI-UL  2800  documents  that  are  under  development,  and  build  on 

1 9  several  years  of  research  and  prototypes  that  have  been  funded  by  US  governmental  grants  in  collaboration  with  NIST. 

20  Note:  This  standard  is  intended  to  be  useful  for  regulatory  purposes. 

21 

22  NOTE  [These  requirements  were  derived  to  sujport  the  clinical  scenarios  or  clinical  concepts  of  operations  describedi 

23  In  Annex  B|. 

24 


25  2  Normative  references 

26  The  following  documents,  in  whole  or  in  part,  are  normatively  referenced  in  this  document  and  are 

27  indispensable  for  its  application.  For  dated  references,  only  the  edition  cited  applies.  For  undated  references, 

28  the  latest  edition  of  the  referenced  document  (including  any  amendments)  applies. 

29  ASTM  F2761 -09(201 3)  Medical  Devices  and  Medical  Systems  -  Essential  safety  requirements  for  equipment 

30  comprising  the  patient-centric  integrated  clinical  environment  (ICE)  -  Part  1:  General  requirements  and 

31  conceptual  model. 

32  ISO  14971 :2007,  Medical  devices  -  Application  of  risk  management  to  medical  devices 

33  lEC  60601-1-8:2006,  Medical  electrical  equipment  -  Part  1-8:  General  requirements  for  basic  safety  and 

34  essential  performance  -  Collateral  Standard:  General  requirements,  tests  and  guidance  for  alarm  systems  in 


35  medical  electrical  equipment  and  medical  electrical  systems 

36  +Amendment  1 :2012 

37  lEC  62304:2006,  Medical  device  software  -  Software  life  cycle  processes 

38  ISO  141 55:201 1 ,  Clinical  investigation  of  medical  devices  for  human  subjects  -  Good  clinical  practice 

39  lEC  80001-1 :201 2,  Application  of  risk  management  for  IT-networks  incorporating  medical  devices 


40  3  Terms  and  definitions 

41  For  the  purposes  of  this  document,  the  following  terms  and  definitions  apply  /  the  terms  and  definitions  given 

42  in  ISO  14971:2007,  lEC  60601-1-8:2006,  F2761-09:2009  and  the  following  apply. 

43  NOTE  An  index  of  defined  terms  is  found  beginning  on  page  29. 

44  4.1 

45  ADVERSE  EVENT 

46  AE 

47  any  untoward  medical  occurrence,  unintended  disease  or  injury,  or  untoward  clinical  signs  (including  abnormal 

48  laboratory  findings)  in  subjects,  users  or  other  persons,  whether  or  not  related  to  the  investigational  medical 

49  device 

50  NOTE  1  This  definition  includes  events  related  to  the  investigational  medical  device  or  the  comparator. 

51  NOTE  2  This  definition  includes  events  related  to  the  procedures  involved. 

52  NOTE  3  For  users  or  other  persons,  this  definition  is  restricted  to  events  related  to  investigational  medical  devices. 

53  [SOURCE:  ISO  14155:201 1 ,  definition  3.2] 

54  4.2 

55  DATA  LOGGER 

56  equipment  that  can  be  used  to  store  (log)  data 

57  4.3 

58  DATA  STORE  (OR  DATA  LOG) 

59  data  repository  of  a  set  of  integrated  objects.  These  objects  are  modelled  using  classes  defined  in  database 

50  schemas.  Data  store  includes  not  only  data  repositories  like  databases;  it  is  a  more  general  concept  that 

51  includes  also  flat  files  that  can  store  data. 

52  [SOURCE:  (Wikipedia  for  now)] 

53  4.x 

54  ELECTRONIC  MEDIA 

55  (1)  Electronic  storage  media  including  memory  devices  in  computers  (hard  drives)  and  any 

36  removable/transportable  digital  memory  medium,  such  as  magnetic  tape  or  disk,  optical  disk,  or  digital 

37  memory  card;  or 

38  (2)  Transmission  media  used  to  exchange  information  already  in  electronic  storage  media.  Transmission 

39  media  include,  for  example,  the  internet  (wide-open),  extranet  (using  internet  technology  to  link  a  business 

70  with  information  accessible  only  to  collaborating  parties),  leased  lines,  dial-up  lines,  private  networks,  and  the 

71  physical  movement  of  removable/transportable  electronic  storage  media.  Certain  transmissions,  including  of 

72  paper,  via  facsimile,  and  of  voice,  via  telephone,  are  not  considered  to  be  transmissions  via  electronic  media, 

73  because  the  information  being  exchanged  did  not  exist  in  electronic  form  before  the  transmission. 

74  [SOURCE:  45  CFR  1 60.1 03] 


75  4.x 

76  ELECTRONIC  PROTECTED  HEALTH  INFORMATION 

77  PROTECTED  HEALTH  INFORMATION  Stored  on  ELECTRONIC  MEDIA 

78  4.4 

79  ICE  DATA  LOGGER 

80  DATA  LOGGER  that  meets  the  requirements  of  this  standard 

81  4.x 

82  INCIDENT 

83  any  fortuitous  or  unexpected  event,  not  being  a  reportable  accident,  by  which  the  safety  of  a  person  is 

84  threatened 

85  [SOURCE:  EUROCAE  floe  number:date,  subclause^ 

86  4.5 

87  LOGGED  DATA 

88 

89  4.x 

90  PROTECTED  HEALTH  INFORMATION 

91  means  individually  identifiable  health  information 

92  [SOURCE:  US  45  CFR  160.103] 

93  4.x 

94  PERSONALLY  IDENTIFIABLE  INFORMATION 

95  relating  to  an  identified  or  identifiable  natural  person  ('data  subject');  an  identifiable  person  is  one  who  can  be 

96  identified,  directly  or  indirectly,  in  particular  by  reference  to  an  identification  number  or  to  one  or  more  factors 

97  specific  to  his  physical,  physiological,  mental,  economic,  cultural  or  social  identity 

98  [SOURCE:  European  Union  Directive  on  Data  Privacy  Joe  number:date,  subclause^ 

99  4.x 

100  RECORDING 

101  act  of  making  certain  data  persistent,  with  a  view  to  subsequent  replay  or  analysis 

102  [SOURCE:  EUROCAE  Joe  number:date,  subclause^ 

103  4.x 

1 04  REPLAY 

105  act  of  reconstructing  the  recorded  situations/scenarios 

106  [SOURCE:  EUROCAE  Joe  number:date,  subclause^ 

107  4.x 

108  TIMEBASE 

109  signal  that  provides  the  reference  time  for  other  recorded  signals 

110  [SOURCE:  EUROCAE  floe  number:date,  subclause#! 


111  4  *  Forensic  data  logging 

112  4.1  *  Recorder  technology 

1 1 3  The  ICE  DATA  LOGGER  Shall  use  a  digital  method  of  recording. 


14  The  ICE  DATA  LOGGER  Shall  not,  under  normal  or  single  fault  conditions,  impair  the  safety  or  performance  of 

15  the  system  in  which  it  is  installed.  Particular  attention  shall  be  directed  to  the  needs  of  life  support  systems  to 

16  ensure  appropriate  physical  and  electrical  segregation  of  the  information  sources  at  the  recording  system 

17  interface. 

18  The  ICE  DATALOGGER  Shall  perform  its  intended  function  under  foreseeable  operating  conditions. 

19  The  maintenance  tasks  required  to  ensure  the  serviceability  and  continued  performance  of  the  ICE  data 

20  LOGGER  shall  be  established  by  the  equipment  manufacturers  and  the  equipment  installers. 

21  The  ICE  DATA  LOGGER  Shall  be  independently  powered  from  systems  from  which  data  is  being  recorded  and 

22  shall  have  backup  power  capabilities  to  allow  continued  recording  from  remaining  powered  devices  and  to 

23  retain  recorded  data.  [Note  -  power  may  be  provided  by  the  device  in  which  the  ICE  DATA  LOGGER  is 

24  physically  integrated] 

25  4.2  *  Recorder  operation 

26  4.2.1  *  Interface 

27  The  ICE  NETWORK  CONTROLLER  Shall  be  interfaced  with  the  ICE  data  logger,  to  provide  data  logging, 

28  stamped  with  a  common  time  base,  of  the  accessible  “state-of-the-clinical  environment”.  Accessible  “state-of- 

29  the-clinical  environment”  shall  mean  those  devices  connected  to  the  ICE  network  controller  that  are 

30  capable  of  transmitting  compliant  data  to  the  ICE  network  controller.  This  includes  waveforms  and  derived 

31  parameters  as  well  as  images,  video  or  audio,  [maybe.  May  be  too  much  data  to  require.  Optional?] 

32  4.2.2  *  Monitoring  of  proper  operation 

33  There  shall  be  aural  or  visual  means  for  pre-use  checking  of  the  ICE  data  logger  for  proper  recording  of  the 

34  information  in  the  recording  medium.  -  should  communicate  status  to  ICE  Network  Manager  which  can 

35  monitor ... 

36  4.2.3  *  Start  and  termination  of  recording 

37  The  ICE  DATALOGGER  shall  start  automatically  to  record  prior  to  the  initiation  of  patient  monitoring  [or:  of  ICE- 

38  attached  medical  device  or  equipment  use]  and  continue  to  record  until  the  termination  of  the  patient 

39  monitoring  [of  the  ICE  session].  In  addition,  (in  the  case  of  a  surgical  procedure),  the  ICE  datalogger  shall 

40  start  to  record  as  early  as  possible  during  the  pre-use  checks  (pre-op)  prior  to  the  beginning  of  a  medical  or 

41  surgical  procedure  and  terminate  following  patient  disconnection  from  monitoring  at  the  end  of  the  procedure. 

42  4.2.4  *  Normal  operation 

43  When  electrical  power  is  applied  to  the  ICE  datalogger  and  the  start  logic  is  satisfied,  the  ICE  datalogger 

44  shall  commence  and  continue  to  store  information,  in  accordance  with  the  requirements  of  this  standard. 

45  [probably  need  to  tie  logging  in  to  ICE  system  check  for  use  on  a  patient,  not  power  up] 

46  4.2.5  *  Time  base  characteristics 

47  A  stable  time  base  or  reference  signal?  shall  be  provided  to  the  ICE  data  logger  having  an  average  accuracy 

48  of  at  least  0.1%  obtained  during  information  retrieval.  The  recorded  time  base  shall  be  reproducible  with  an 

49  accuracy  of  0.1%,  averaged  over  a  period  of  at  least  1  minute. 

50  4.3  *  Data  recording  and  storage 

51  4.3.1  *  Stored  data 

52  The  ICE  DATA  LOGGER  shall  save  logged  data  in  a  data  store  (or  Data  LOG).  This  data  shall  include  all 

53  user/operator  interactions  with  ICE  components  such  as  key-presses,  connections/disconnections  of 


154  equipment,  starting/ending  of  procedure(s),  and  data  on  the  device  operating  mode  (or  “state”  such  as 

155  calibration,  standby,  active).  [JG  note  -  If  this  is  a  clinical  procedure,  this  may  not  possible.  If  equipment-based 

156  procedure,  it  may  be] 

157  All  data  in  the  data  store  shall  be  in  non-proprietary  formats. 

1 58  NOTE  :  Available  standards  for  data  encoding  should  be  applied. 

159  Master  index  of  data  recorded  shall  be  maintained  and  updated  during  the  recording  session. 

160  NOTE  1  While  all  “user-equipment”  interactions  may  not  be  accessible  to  the  ICE,  those  interactions  identified  as 

161  important  in  mitigating  identified  patient  hazards  and  which  are  accessible  should  be  logged,  and  those  not  capable  of 

162  being  logged  but  identified  as  important  in  hazard  mitigation  should  be  considered  as  future  product  enhancements  by 

163  relevant  device  manufacturers  and  future  additions  to  device  and  communication  standards  by  standards  development 

1 64  organizations. 

165  Note  2  The  MDIDS  project  documents  could  provide  a  list  of  device  outputs  and  inputs  suitable  for  data 

166  logging 

1 67  NOTE  2  The  data  store  may  be  physically  co-located  to  the  ICE  or  may  be  remotely  located  as  long  as  the  ICE  data 

168  LOGGER  is  sufficiently  robust  to  comply  with  the  requirements  of  this  standard,  [need  requirement  for  local  data  store  to 

1 69  manage  network  interruption  -  including  deliberate/malicious  interruptions] 

170  4.3.2  *  Volume  and  velocity 

171  The  ICE  DATA  LOGGER  Shall  be  able  to  record  a  sufficient  number  of  hours  of  Logged  Data  in  the  data  store 

1 72  sufficient  for  the  intended  environment  of  use,  equipment  configuration  and  the  specifics  of  the  patient. 

1 73  NCTE  1  The  volume,  velocity  and  type  of  logged  data  can  vary  over  a  wide  range,  and  a  data  store  should  be 

1 74  capable  of  storing  in  real  time  the  maximum  expected  volume  of  data  for  the  intended  environments  of  use.  [probably  need 

175  to  add  a  minimum  number  of  hours-  72  hours?]  [Will  data  be  over-written  in  circular  buffer?  Dependent  on  Mode  Section 

176  4.4?] 

177  4.3.3  *  Time  stamping 

178  The  ICE  DATA  LOGGER  shall  record  time  stamps  associated  with  each  received  data  packet.  These  time 

179  stamps  should  be  based  on  the  ICE  Network  Controller  clock  time  reference  and  using  real-time  clock 

180  synchronization  mechanisms  (such  as  Network  Time  Protocol)  on  every  message  for  the  time  the  message 

181  was  received  and  the  time  the  message/data  was  stored. 

182  4.3.4  *  Quality  of  service 

183  Quality  of  Service  indicators  of  the  ICE  data  logger  shall  be  recorded  and  shall  include  metrics  on  the 

1 84  accuracy  of  the  synchronization,  and  degree  of  lossless  compression. 

1 85  NOTE  1  Quality  of  Service  (QoS)  indicators  may  include  bandwidth,  latency,  and  jitter. 

186  4.3.5  *  Patient  and  device  identification 

187  Patient  demographics  shall  be  stored  in  the  data  store  (or  DATA  LOG).  Each  data  transmission  from  a 

188  device  to  the  ICE  shall  include  a  unique  numeric  or  alphanumeric  code  which  identifies  the  specific  device, 

189  including  manufacturer,  model  and  serial  number. 

1 90  NOTE  1  The  FDA’s  unique  device  identifier  (UDI)  encoding  is  expected  to  satisfy  these  requirements. 


31  4.3.6  *  Security 

32  Access  to  the  data  store  shall  be  controlled  by,  at  a  minimum,  password  protection  and  shall  be  consistent 

33  with  the  general  principles  of  confidentiality.  Integrity  and  availability.  Means  shall  be  provided  to  restrict 

34  access  to  the  data  store  to  the  responsible  organization  and  responsible  parties. 

35  4.3.7  *  Privacy 

36  Protected  health  information  shall  be  encrypted  using  a  confidential  process  consistent  with  NIST  Special 

37  Publication  800-1 1 1 ,  Guide  to  Storage  Encryption  Technologies  for  End  User  Devices. 

38  NOTE  Compliance  with  the  HIPAA  Security  Rule  which  states  “the  use  of  an  algorithmic  process  to  transform 

39  data  Into  a  form  In  which  there  Is  a  low  probability  of  assigning  meaning  without  use  of  a  confidential  process 
DO  or  key”  Is  encouraged  (45  CFR  164.304  definition  of  encryption). 

31  4.3.8  *  Reiiabiiity 

32  Features  to  enhance  reliability  and  security  Include  use  of  a  unique  Incremental  sequence  number  for  each 

33  log  entry  by  the  ICE  data  logger,  use  of  a  protected  data  store,  and  use  of  a  cryptographic  signature  to  each 

34  log  entry. 

35  4.4  *  Operating  recording  modes 

36  An  ICE  DATA  LOGGER,  fully  compliant  with  this  standard,  shall  support  the  following  operating  recording  modes: 

37  a)  clinical  mode 

38  b)  technical/  troubleshooting  mode 

39  c)  complete  mode 

10  Cniy  one  logging  mode  shall  be  supported  concurrently.  The  contents  of  the  data  store  for  each  logging 

1 1  mode  shall  stack  In  Incremental  layers:  clinical  <  technical  <  complete  (Figure  x).  The  level  of  compliance  shall 

12  be  determined  by  qualification  testing. 
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Figure  x  -  Stacking  of  data  contents  for  each  logging  mode  [may  need  to  redraw  figure  based  on  committeel 
suggestion)  [WG03  note  -  Consider  level  of  prescription  indicated  in  this  figure,  i.e.  is  it  too  prescriptive  or  not 
enough.  Also  consider  the  forensic  purpose  of  the  data  logger  and  evaluate  that  the  image  reflects  that 
purpose. ] 


4.4.1  *  Clinical  mode 

An  ICE  DATA  LOGGER  operating  in  Clinical  Mode  shall  store  in  the  data  store  the  following: 

a)  all  available  physiologic  waveforms; 

b)  all  available  clinical  parameters; 

c)  any  error  codes; 

d)  any  alarms  or  alerts; 

e)  any  change  in  status; 

f)  any  user-entered  data; 

g)  any  key  presses;  and 

h)  configuration  information  (including  software  versions) 
from  all  the  ICE-connected  devices. 

NOTE  1  Physiologic  waveform  includes  waveforms  that  are  displayed  and  those  waveforms  that  are  selectable  for 
display  on  ICE-connected  devices.  This  may  change  during  the  course  of  a  surgical  case  or  an  intensive  care  unit  stay. 

NOTE  2  Clinical  parameters  include  all  parameters  that  are  displayed  and  are  selectable  for  display].  Relevant  to  caril 
of  particular  patient????  [standard  must  reinforce  notion  of  what  is  required  from  devices,  i.e.  for  devices  to  be  good  actors 
in  this  ecosystem,  they  must  do  x  and  y.  Example:  Device  EDI  should  communicate  all  data  that  is  capable  of  being 
displayed  for  use  by  the  operator,  technical  and  clinical  alarm  messages,  clinical  arm  threshold  settings,  device  state  and 
changes  in  state  (such  as  standby,  operational,  calibrating,  infusing,  stopped  infusing,  catheter  blockage,  low  battery,  time 
remaining  on  battery,  service  needed,  sensor  expired,  operating  temp  exceeded,  cal  required,  etc.  Insert  reference  from 
STA  meeting  that  describes  above  concept] 

p:  What  data  goes  into  the  data  store?  Data  relevant  to  clinical  situation?  All  parameters  that  can  be| 
pisplayed  or  transmitted?! 

Figure  with  data  flows???] 

4.4.2  *  Technical/ troubleshooting  mode 

An  ICE  DATA  LOGGER  operating  in  Technical/Troubleshooting  Mode  shall  store  in  the  data  store  the  following: 

a)  All  data  stored  in  Clinical  Mode  and 

b)  Diagnostic  data  from  connected  devices. 

4.4.3  *  Complete  mode 

An  ICE  DATA  LOGGER  operating  in  Complete  Mode  shall  store  in  the  data  store  the  following: 


a)  All  data  stored  in  Technical/Troubleshooting  Mode  and 


51  b)  All  network  packets/traffic  available  to  the  ICE  data  logger. 

52  4.5  *  Post-data  analysis,  data  reduction  and  retrieval 

53  The  logged  data  shall  be  stored  In  a  data  store  (data  log)  which  shall  permit  the  post-recording  data  retrieval 

54  for  data  analysis  and  reduction  of  Identified  and  de-ldentifled  data  to  3'^'^  party  applications. 

55  The  replay  of  a  recording  made  by  any  ICE  data  logger  shall  be  capable  of  being  synchronized  In  time  with 

56  any  other  required  recording  to  within  1  second. 

57  The  bit  error  rate  arising  from  differences  between  the  Input  and  the  retrieved  data  caused  by  corruption  of  the 

58  data  during  processing,  recording  and  retrieval  shall  not  exceed  one  error  In  10®  bits.  In  addition,  where  data 

59  compression  Is  used,  the  word  error  rate  shall  not  exceed  one  error  In  1 0®  words. 

50  Following  the  removal  of  electrical  power  to  the  ICE  datalogger,  the  recording  medium  shall  be  capable  of 

51  retaining  the  Information  recorded  during  the  preceding  operating  time  for  a  period  of  at  least  2  years,  [within  a 

52  storage  temp  range?  And  humidity?] 

53  NOTE  1  These  applications  include  automated  data  extraction  for  adverse  event  reports  and  automated  screening  for 

54  adverse  events  and  incidents. 

55  4.5.1  *  Adverse  events 

56  Existing  ADVERSE  EVENT  ontologies  should  be  used,  such  as  the  device  problem  and  evaluation  codes  as 

57  specified  for  the  FDA’s  Medical  Device  Reporting  (MDR)  system,  [placeholder  to  extend/improve  as  the  terms 

58  expand?] 

59  4.6  *  Archiving 

70  The  DATA  STORE  for  a  patient  stay  or  procedure  shall  be  stored  securely  on  electronic  media  for  the  duration  of 

71  a  patient’s  stay  in  the  hospital  plus  30  days,  consistent  with  written  policies  of  the  institution. 

72  (life  of  data?  storage?  Media?  -  cloud?  Passive  storage? 


73  5  *  General  requirements 

74  5.1  Risk  management  process 

75  A  RISK  MANAGEMENT  PROCESS  complying  with  ISO  14971 :2007  shall  be  performed  for  an  ICE  data  logger. 

76  In  applying  ISO  14971 :2007: 

77  —  The  term  'medical  device'  shall  assume  the  same  meaning  as  a  medical  device  incorporating  an 

78  ICE  EOUIPMENT  INTERFACE. 

79  —  The  policy  for  determining  acceptable  risk  and  the  acceptability  of  residual  risk(s)  shall  be  established 

30  by  the  MANUFACTURER. 

31  Check  compliance  by  inspection  of  the  risk  management  file.  The  requirements  of  this  subclause  are 

32  considered  to  be  satisfied  if  the  manufacturer  has: 

33  —  established  a  RISK  MANAGEMENT  process; 

34  —  established  acceptable  levels  of  risk;  and 


285  —  demonstrated  that  the  residual  risk(s)  is  acceptable  (in  accordance  with  the  policy  for  determining 

286  acceptable  risk). 

287  5.2  *  ICE  EQUIPMENT  INTERFACE  qualification  test 

288  The  MANUFACTURER  of  equipment  that  includes  an  ice  equipment  interface  shall  develop  a  qualification  test 

289  suitable  for  use  by  a  responsible  organization  to  verify  those  portions  of  the  basic  safety  and  essential 

290  performance  of  that  ice-compatible  equipment  that  can  be  affected  by  the  ice  equipment  interface  of  the 

291  ICE  DATA  LOGGER.  This  qualification  test  shall  be  disclosed  in  the  technical  description. 

292  The  technical  description  shall  include  a  reference  to  lEC  80001-1  and  the  necessity  of  the  responsible 

293  ORGANIZATION  to  perform  risk  management,  including  the  qualification  test  for  the  ice-compatible  equipment, 

294  prior  to  placing  the  system  into  service. 

295  The  instructions  for  use  shall  include  an  indication  that  this  qualification  test  is  described  in  the  technical 

296  description  and  is  required  to  be  performed  prior  to  placing  the  equipment  into  service. 

297  Check  compliance  by  inspection  of  the  instructions  for  use  and  technical  description. 

298  5.3  Software 

299  The  requirements  of  lEC  62304:2006  shall  apply  to  the  software  of  an  ICE  data  logger. 

300  Check  compliance  by  inspection  of  the  validation  reports  demonstrating  compliance  with  the  requirements  of 

301  I  EC  62304:2006. 

302  5.4  Communication  management 

303  The  ICE  DATA  LOGGER  Shall  maintain  basic  safety  and  essential  performance  in  normal  condition  and 

304  SINGLE  FAULT  CONDITION.  The  following  principles  are  intended  to  guide  the  development  of  the  other  parts  of 

305  this  standard: 

306  a)  The  connected  ice-compatible  equipment  does  not  fail  due  to  receipt  of  messages  or  other  information; 

307  and 

308  b)  The  ICE  NETWORK  CONTROLLER  does  not  fail  due  to  receipt  of  messages  or  other  information  that  do  not 

309  conform  to  the  device  model  of  the  sending  connected  ice-compatible  equipment; 

310  Specific  error  scenarios  to  be  considered  in  the  verification  of  ice-compatible  equipment  should  include  the 

311  following: 

312  c)  failures  caused  by  direct  or  indirect  connection,  electrical  and  logical,  of  ICE  components  to  the  ice- 

313  COMPATIBLE  equipment; 

314  d)  failures  caused  by  erroneous  commands; 

315  e)  failures  caused  by  receiving  and  processing  erroneous  data  or  commands;  and 

316  f)  failures  caused  by  not  adhering  to  the  non-functional  requirements  of  the  communication  specification. 

317  Check  compliance  by  application  of  the  tests  of  the  remaining  parts  ofASTM  F2761-09(13). 
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Annex  B 
(informative) 


Guidance  and  rationaie 


29  B.1  General  guidance 

30  This  Annex  provides  a  rationaie  and  guidance  for  certain  requirements  of  this  standard  and  is  intended  for 

31  those  who  are  famiiiar  with  the  design  and  use  of  the  ice  data  logger  but  who  have  not  participated  in  its 

32  deveiopment.  An  understanding  of  the  reasons  for  these  requirements  is  provided  to  aid  in  the  appiication  of 

33  this  standard.  Furthermore,  as  ciinicai  practice  and  technoiogy  change,  it  is  beiieved  that  a  rationaie  for  the 

34  present  requirements  wiii  faciiitate  a  revision  of  this  standard  necessitated  by  those  deveiopments. 


35  B.2  Rationale  and  guidance  for  particular  clauses  and  subclauses 

36  The  numbering  of  the  foiiowing  rationaie  corresponds  to  the  numbering  of  the  ciauses  and  subciauses  in  this 

37  document. 

38  Clause  1  Scope 


39  The  foiiowina  2  garaflraBhs  were  written  for  a  previous  scope  statement.  There  is  a  need  to  revisit  this  section.1 

40  Part  1  of  this  standard  series  introduces  a  specific  conceptuai  functionai  modei  for  defining  the  ice.  The  modei 

41  defines  separate  functions  that  comprise  the  ice  and  inciudes  the  iCE  data  logger  A  ciinicai  benefit  of 

42  integrating  standaione  medical  devices  is  the  abiiity  to  combine  the  data  coiiected  from  different  sources  to 

43  yieid  new  information,  in  ways  that  are  not  possibie  with  stand-aione  medical  devices  and  equipment. 

44  Additionai  ciinicai  benefits  of  integration  by  the  ice  inciude  decision  support,  the  abiiity  to  impiement  distributed 

45  controi  of  medical  devices  for  safety  interiocks  and  ciosed  ioop  controi  and  the  abiiity  to  record  the  state  of  the 

46  ciinicai  environment  using  an  iCE  data  logger  (the  subject  of  this  standard).  Exampies  of  such  benefits  are 

47  found  in  Annex  B  of  Part  1  of  this  standard  series. 

48  Part  2  of  this  “iCE”  standard  series  (this  standard)  presents  requirements  of  and  a  modei  of  a  forensic  data 

49  iogger  that  is  intended  to  be  interfaced  to  iCE  network  controller.  A  forensic  data  iogger  is  intended  to 

50  record  data  during  the  time  a  patient  is  undergoing  care  monitored  (such  as  during  a  surgicai  procedure  or 

51  treatment  in  the  intensive  Care  Unit).  Aii  piayback  and  anaiysis  of  the  recorded  data  is  intended  to  occur  after 

52  termination  of  the  recording  period 

53  Why  use  a  data  iogger? 

54  •  Change  our  reactive  safety  cuiture 

55  •  Lack  of  usefui  information  in  incident/accident  investigations 

56  •  Lack  of  aggregate  safety  data  to  make  iong  term  safety  improvements 

57  •  How  do  you  fix  what  you  don’t  know? 

58  •  Discrepancy  reports 

59  (From  American  Eurocopter  presentation  -  why  do  we  need  flight  data?) 

50  Data  recorders  have  been  used  for  forensic  purposes  in  transportation  over  the  iast  century  and  have  become 

51  through  the  deveiopment  of  standards  and  passage  of  iegisiation  required  and/or  commonpiace  in  commerciai 

52  aircraft,  automobiies,  and  iarger  ships.  Logging  the  data  of  the  “ciinicai  environment  for  forensic,  quaiity  and 

53  other  purposes  remains  iimited  in  scope  and  scaie.  The  experiences  of  these  transportation  data  ioggers 

54  improves  the  understanding  and  faciiitation  of  soiutions  reiative  to  iikeiy  issues  to  encountered  with  its  wide- 

55  scaie  impiementation. 
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367  Table  1  -  Data  Recorder  Types  and  Standards  in  Transportation 


Mode/Type* 

Photo 

Standard(s) 

Legal  Ref. 

Status 

Notes 

Airplanes 

FDR 

EUROCAE 

ED-112 

14  CFR  25.1459 

14  CFR  121.344 

Mandatory 

Larger  aircraft 

Flelicopters 

FDR 

Guidelines 

only 

49  use  44730 
** 

Optional 

Video  included 

Motor  vehicles 
(cars/trucks) 

EDR 

“I 

I 

1^3  iiiilimilMi  It  ^1 

IEEE  1616a 

SAE  J2728 
(2010) 

49  CFR  563 

Soon  to  be 
mandatory 

Rules  different 

between 

cars/trucks 

Trains 

EDR 

IEEE  1482.1 

GM/RT  2472 

49  CFR  229.135 

Ships 

SVDR 

[ 

lEC  61996 

(2013) 

SOLAS 

Mandatory? 

368  *  FDR-  flight  data  recorder,  VDR  -  voyage  data  recorder,  EDR  -  event  data  recorder 

369  **Air  ambulances 

370  The  data  logging  capabilities  and  characteristics  of  selected  medical  devices  with  varying  capabilities  - 

371  including  ambulatory  data  loggers  (e.g.  digital  Holter  recorders),  handheld  monitors  (e.g.  combined  Sp02  and 

372  C02),  laboratory  data  recorders  (e.g.  sleep  diagnostics  systems),  multi-parameter  respiratory  monitors,  multi- 

373  parameter  physiologic  monitoring  systems  ,  anesthesia  workstations,  and  ventilators  -  vary  significantly  with 

374  respect  to  the  capabilities,  data  formats,  and  bandwidth  requirements. 

375  INSERT  SECTION  ON  importance  of  data  logging  to  manage  manufacturer  product  liability  related  to 

376  interoperability  and  logging  as  a  driver  for  adoption  of  interoperability  (cannot  log  what  cannot  be  accessed) 

377  [JMG  to  add} 

378 

379  INSERT  -  section  on  history  of  ICE  DAT  LOGGER  foundational  work  -  see 

380  http://mdpnp.org/MD  PnP  Program  DataLogger.html  and  publications,  web  sites.  [JMG  to  add] 
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Table  x  -  Comparison  between  Individual  Device  and  ICE  Data  Logger  Capabilities 


Individual  Devices 

ICE  Data  Logger 

Notes 

Data  logging 

Capabilities  limited  by 
design  choices  of  each 
manufacturer. 
Manufacturer 
proprietary  data  may  be 
stored. 

May  be  mandated  by 
new  and  emerging 
standards. 

Allows  for  time- 

synchronized  log  of 
ICE-connected  device  in 
use  (medical  devices 
and  other  equipment). 
Can  provide  greater 
flexibility  including 

virtual  and  distributed 
models  of  data  logging 

Types  of  logging 

Varies,  often  only 

averaged  data  is  logged 

Allows  for  clinical  data 
logging,  event  logging 
and  debugging  data 
logging 

Debugging  logging 

includes  recording  of 
network  traffic 

Adverse  Event/Near 
Miss  Analysis 

Difficult  to  undertake  if 
greater  than  a  single 
device  is  in  use,  due  in 
part  to  difficulty  of  time¬ 
aligning  data  logs. 

Allows  for  a  more 
complete  picture  of  the 
clinical  environment  to 
be  captured  with  less 
effort  and  cost 

ICE  data  logger  provides 
opportunities  for  quality 
control  and  ongoing 
monitoring  and 

assessment 

Protocols 

Priority  protocols  and 
encoding  formats 

Data  formatted  in 

common  or  known 
ontology  for  each  device 

Aspects  of  11073,  HL7  or 
SNOMED  can  be  adopted 
as  the  common  protocol 
and  encoding  approach 

Time  synchronization 

Different  time  bases 
unless  all  devices  are 
synced  via  NTP  or  other 
approach 

Common  time  base 

ICE  data  logger  has 
common  time  base, 
records  time  from  devices 
and  will  use  logical  clocks 
to  assure  proper 

sequencing 

Security  and 

Trustworthiness  of 

Log 

Dependent  on  design  of 
each  device 

Vendor-neutral  record 

Vendor-neutral  record  to 
serve  as  ?legal  record? 

Given  the  wide  range  and  differences  in  device  output  data  streams  and  capabilities,  it  is  daunting  to  try  to 
combine  measurements  from  devices  from  different  manufacturers  and  sometimes  even  the  same 
manufacturers.  This  is  further  complicated  by  the  need  for  efficient  mechanisms  for  data  playback  for  adverse 
event/near-miss  investigation  and  reporting.  The  idea  of  playback  of  limited  (usually  from  a  single  device)  data 
sets  does  exist.  For  example,  ambulatory  recording  devices  have  developed  a  sophisticated  suite  of  tools  for 
analysis  of  limited  clinical  data  sets. 

A  data/patient-centric  approach  will  allow  plug-and-play  devices  using  data-centric  protocols  and  an  ICE  data 
logger  to  work  seamlessly,  in  an  open,  standardized,  and  time-synchronized  manner,  as  compared  to 
individual  device-based  approaches.  These  advantages  include  more  efficient  adverse  event/near  miss 
analysis,  common  protocols  and  time  base,  and  improved  security.  Such  an  approach  permits  new 
opportunities  for  improved  patient  monitoring  and  safety.  This  is  distinct  from  the  capabilities  of  the  EHR, 
which  uses  lower  granularity  data  storage  (e.g.  one  minute)  and  can  fail  to  capture  clinically  significant  outliers, 
[xxx] 
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With  each  device  uniquely  identified  (e.g.  by  UDI)  and  data  formatted  in  a  common  or  known  ontology,  new 
opportunities  for  improvements  in  adverse  event  investigation  will  be  enabled,  similar  to  those  enabled  by  the 
data  recorders  used  in  transportation  such  as  the  flight  data  recorder.  Challenges  with  current  approaches  to 
adverse  event  analysis,  including  device  location  and  sequestering,  manual  data  entry,  differences  in  clock 
timing,  and  problems  with  data  extraction,  are  reduced.  Debugging  logs  including  network  interactions  can 
facilitate  sophisticated  debugging  of  device  interactions,  which  may  assist  with  clinical  event  analysis. 
Significant  work  will  be  required  to  develop  effective  playback  tools. 


The  DL  is  intended  to  be  a  highly  secure  and  reliable  data  store.  The  DL  -  although  interfaced  to  the  ICE 
Network  Controller  (INC)  -  need  not  be  a  physical  “black-box”  recorder  but  may  reside  locally  or  in  the  cloud. 
It  must  meet  demanding  data  requirements,  including  high  reliability,  time  synchronization,  privacy  and 
security  (compliant  with  HIMSS  Information  Security  Best  Practices).  The  DL  is  intended  to  be  limited  to  the 
capture  and  storage  of  data  with  no  interpretation  of  data  content  performed  by  the  DL.  That  function  is 
intended  for  components  external  to  the  DL  that  run  post-data  capture  on  the  DL  data  store. 


^uncan  Radiology  Management 

Improvement  strategy  has  three  major  components 


l.Continually  capturing  data  on  current  performance 


Analyzing  that  data  to  identify  improvement  opportunities 


Allowing  the  frontline  staff  to  pursue  small  tests  of  change  as  they  strive  to  improve  their  performances 
minimum  data  set  -  per  FDA  form  35^ 


The  data  logger  records  all  data  requests,  transactions  and  flows  and  as  such  represents  a  complete  audit 
trail  of  all  activities  carried  out  by  and  through  the  ICE.  These  logs  should  have  similar  uses  as  a  “black  box” 
flight  recorder  in  modern  aircraft.  It  is  desirable  that  the  logs  be  as  complete  as  possible,  and  can  be 
“replayed”  after  the  fact,  e.g.  to  allow  for  forensic  reconstruction  of  events  that  lead  to  a  specific  outcome.  It 
must,  therefore,  only  be  accessible  through  a  controlled  environment,  i.e.  an  ICE,  even  if  that  ICE  is  for  the 
specific  purpose  of  accessing  the  data  logger’s  logs.  Physical  and  cryptographic  protection  mechanisms  will 
be  used  to  prevent  improper  access  or  tampering. 


4*  Forensic  data  logging 

5.5  Recorder  technology 

5.6  Recorder  operation 

5.6.1  Interface 

5.6.2  Monitoring  of  proper  operation 

I 

5.6.3  Start  and  termination  of  recording 


I 


35 


5.6.4  Normal  operation 


36 

37  5.6.5  Time  base  characteristics 

38  XX. 

39  5.7  *  Data  recording  and  storage 

40  5.7.1  Stored  data 

41 

42  5.7.2  *  Volume  and  velocity 

43  The  intended  environment  of  use  is  intended  to  include  all  clinical  environments  in  which  a  patient  may  be 

44  connected  to  medical  devices  which  are  capable  of  transmitting  electronic  data. 

45  The  equipment  configuration  can  range  from  a  heavily  monitored  environment  which  may  include  waveforms, 

46  numeric  parameter,  images,  video  and  auditory  inputs  to  a  more  simple  ambulatory  environment.  The 

47  connected  devices  can  include  multi-parameter  monitors  with  the  capability  of  transmitting  numerous 

48  parameters,  simple  devices  communicating  a  single  parameter  to  wearable  sensors  which  may  transmit  data 

49  directly  to  or  through  a  hub  to  the  ICE. 

50  The  volume,  velocity  and  type  of  data  can  vary  significantly  and  the  data  store  should  be  appropriately  sized 

51  to  accommodate  such  data.  (Automatic  estimation  of  data  store  needs  at  the  start  of  a  case  or  monitoring 

52  Session??  To  determine  if  potential  problem?^he  volume  of  data 

53  The  velocity  of  physiologic  waveform  varies  on  the  type  of  physiologic  signal  (and  body  system  being 

54  measured)  and  tend  range  from  several  samples  per  second  to  hundreds  of  samples  per  second. 

55  Table  X 

56  Signal  Data  sampling  Range 

57 

58  Capnogram  20-100  samples/sec 

59  ECG  100-250  samples  sec 

50  Neuro 

31  5.7.3  Time  stamping 

52  Medical  device  clock  errors  are  a  pervasive  problem  that  negatively  impacts  the  accuracy  of  time  data  in 

53  EMRs  and  in  the  reconstruction  of  clinical  events,  as  well  as  posing  a  direct  hazard  to  patient  safety.  Most 

54  medical  devices  contain  an  internal  clock  that  is  used  to  timestamp  data  in  internal  logs  as  well  as  any 

55  information  the  device  sends  over  its  network  interfaces.  There  is  no  adopted  standard  for  medical  device  time 

56  management,  and  many  medical  devices  do  not  set  their  clocks  using  a  network  time  reference,  but  are 

57  typically  set  manually  twice  yearly  for  daylight  savings  time.  The  absence  of  automatic  clock-setting 

58  capabilities  in  most  devices,  and  the  lack  of  time  synchronization  among  the  wide  array  of  different  clocks  in 

59  use  in  a  typical  OR  or  ICU,  can  result  in  inaccurate  time-stamps  on  clinical  data  recorded  in  the  EMR. 

70  A  study  at  MGH  and  4  other  institutions  [ref]  showed  that  erroneous  clock  times  are  pervasive.  Given  the 

71  absence  of  automatic  clock  setting  capabilities  in  most  medical  devices,  and  typical  clock  drift,  these  finding 

72  are  not  surprising,  but  consequences  are  underestimated.  The  collected  data  indicates  a  need  for  a  central 

73  network  controller  to  monitor  and  adjust  device  clocks.  Networking  medical  device  clocks  would  not  only 

74  improve  medical  record  accuracy,  but  also  greatly  reduce  technician  man-hours  spent  setting  and  resetting 

75  clocks  during  power  outages,  surges,  or  daylight  saving  time.  The  networked  devices  show  a  much  lower 

76  standard  deviation  as  compared  to  standalone  devices  which  show  a  high  deviation  from  the  average  values 

77  since  their  only  means  of  synchronization  is  by  detection  and  manual  correction  from  the  hospital  staff 
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5.7.4 *  *  Quality  of  service 


Duality  of  Service  indicators  of  the  ICE  datalogger  shall  be  recorded  and  included  metrics  on  the  accuracjd 
pf  the  sMichronization,  and  degree  of  lossless  comBressionj 

Note  1  Quallter  of  service  fQoSS  indicators  mag  include  bandwidth,  latencg,  and  Jittij 

5.7.5  *  Patient  and  device  identification 

Patient  demographics 


Unique  device  identification.. | 

5.7.6  *  Security 

The  access  to  the  data  store  is  intended  to  be  consistent  with  accepted  cybersecurity  principles  including 
those  outlined  in  FDA’s  draft  Guidance  titled  “Content  of  Premarket  Submissions  for  Management  of 
Cybersecurity  in  Medical  Devices.  The  access  of  restricted  information  should  be  to  only  trusted  users. 
Safeguards  should  be  in  place  to  ensure  that  the  information  is  accurate  and  not  improperly  modified  and  that 
information  should  be  accessible  on  a  timely  basis. 

The  cybersecurity  of  the  data  store  should  be  validated  by  hazard  analysis  and  design.  Software  to  access 
the  data  store  should  be  regularly  screened  by  anti-virus  softwareL  firewall  use  to  users^ 

[Ensure  secure  data  transfer  from  medical  devices  to  data  store  and  post-recordinj  from  data  store  to  anaiSfsij 
software,  use  accepted  methods  of  eng^tion.| 

Fail-safe  features  to  protect  critical  functionallfejl 

Features  that  allow  security  compromise  to  be  recognized,  logged  and  acted  upon 


*  Privacy 

Protected  health  informatioi^ 

HIPAA 

Different  definitions  between  EU  and  US 


5.7.7  *  Reliability 

Features  to  enhance  reliability  and  security  include  use  of  a  unique  incremental  sequence  number  for  each 
log  entry  by  the  ICE  data  logger,  use  of  a  protected  data  store,  and  use  of  a  cryptographic  signature  to  each 
log  entry. 

5.8  *  Operating  recording  modes 


Rationale  for  different  modes 


10  5.8.1  Clinical  mode 

11  Data  recorded  in  Clinical  mode  is  intended  to  capture  the  information  representing  the  Accessible  “state-of- 

12  the-clinical  environment. 

13  Figure  with  data  flows???| 

14  5.8.2  Technical/ troubleshooting  mode 

15  In  addition  to  the  clinical  parameters  and  waveforms  interpreted  by  the  clinician,  medical  devices  transmit  data 

16  for  diagnostic  and  safety  purposes  data  on  the  status  of  various  components  of  devices  including  aspects  of 

17  their  measurement  and  control  systems. 


Waveform/  Clinical 
Measurement(s) 

Technology 

Ancillary  Data 
(examples) 

Potential  Clinical 
Value 

(if  applicable) 

Capnogram 

(e.g.  PetC02) 

Infrared  Spectroscopy 

a.  Temperature  of  heating 

element, 

b.  flow  rate  of  sampling 

pump 

a.  risk  of  injury? 

b.  reliability  of 

measurement 

Blood  Pressure 

Oscillometry 

a. Maximum  cuff  pressure 

a.  injury? 

(e.g.  Systolic/Diastolic 

pressure) 

b.  indication  of  start  and 
end  of  inflation 

b.  input  to  decision 
support  regarding  pulse 
oximeter  on  same  limb 

Infusion  pump 

18 

19  5.8.3  Complete  mode 

20 
21 

22  5.9  Post-data  analysis,  data  reduction  and  retrieval 

23  The  ICE  Data  Store  contains  sensitive  data  and  protected  health  information.  Procedures  shall  be  established 

24  to  control  the  release  and  transfer  of  such  data.  In  the  event  of  an  adverse  event  or  incident,  assigned  staff 

25  and  external  regulatory  staff  (e.g.  FDA)  should  be  allowed  unfettered  access.  Software  tools  are  imagined  to 

26  perform  post-event  analysis  of  the  data  store.  A  report  consistent  with  Federal,  State  and  Local  regulatory 

27  requirements  can  be  generated  from  the  data  store  permitting  a  more  transparent,  robust  and  rapid  analysis  to 

28  performed  of  the  adverse  event. 

29  5.9.1  *  Adverse  events 

30  The  Medical  Device  Reporting  (MDR)  regulation  (21  CFR  803.1)  requires  that  manufacturers  and  health 

31  professionals  “report  deaths  and  serious  injuries  that  (a)  device  has  or  may  have  caused  or  contributed  to.” 

32  These  reports  are  used  to  “protect  the  public  health  by  helping  to  ensure  that  devices  are  ...  safe  and  effective 

33  for  their  intended  use.”  The  adverse  event  reports  focus  on  capturing  and  documenting  the  event  data  (e.g. 


534  date  of  event,  date  of  report,  description  of  event),  details  on  the  medical  device  (e.g.  manufacturer,  serial 

535  number)  and  basic  patient  demographics.  In  contrast  to  the  MDR,  the  perspective  of  the  availability  of  a 

536  forensic  data  store  call  help  automate  the  data  collection  for  MDRs  and  help  to  identify  events  and/or  elicit 

537  ideas  for  system-level  solutions  that  cross  the  boundaries  of  specific  manufacturers,  regulated  and  non- 

538  regulated  products,  diverse  users,  and  practice  variability. 

539  Developers  of  analysis  and  automated  reporting  tools  are  strongly  encouraged  to  use  the  Event  Problem 

540  Code  terminology  for  the  reporting  of  medical  device  problems  developed  by  CDRH.  This  code  terminology 

541  consists  of  three  term  sets,  covering  Patient  Problem  Codes,  Device  Component  Codes,  and  Device  Problem 

542  Codes.  Patient  Problem  Codes  include  patient  conditions/dieases  (e.g.  Adult  Respiratory  Distress  Syndrome). 

543  Device  Problem  Codes  include  codes  for  device  operational  issues  (e.g.  device  stops  intermittently,  therapy 

544  delivered  to  incorrect  body  area),  facilities  issues  (e.g.  Failure  to  Service),  human  factors  issues  (e.g.  difficult 

545  to  program  or  calibrate),  and  physical  property  issues  (e.g.  Device  emits  odor)  and  Component  Code 

546  Hierarchy  (e.g.  vaporizer). 

547  5.10  Archiving 

548  The  DATA  STORE  for  a  patient  stay  or  procedure  shall  be  stored  securely  on  electronic  media  for  the  duration  of 

549  a  patients  stay  in  the  hospital  plus  30  days  consistent  with  written  policies  of  the  institution. 

550  (life  of  data?  storage?  Media?  -  cloud?  Passive  storage? 

551 


Annex  C 
(informative) 


52 

53 

54 

55  Ciinicai  context  and  ciinicai  scenarios 


56  C.1  Purpose  and  introduction 

57  C.1.1  Purpose 

58  The  purpose  of  this  Annex  is  to  provide  the  clinical  context  for  the  development  of  standards  for  integrated 

59  medical  device  systems.  The  Clinical  Scenarios  below  illustrate  serious  adverse  events  that  could  have  been 

50  prevented  through  integrated  medical  systems,  thus  representing  unmet  safety  and  performance  needs.  The 

51  examples  are  representative,  not  exhaustive. 

52  The  Medical  Device  “Plug-and-Play”  Interoperability  program  nsiErroi-!  Reference  source  not  found.  identified  high- 

53  level  Clinical  Scenarios  from  clinical  publications,  web  sites,  and  interviews  (“focus  groups”)  with  clinicians  and 

54  engineers,  These  scenarios  have  been  expanded  into  “use  cases”  to  aid  in  the  development  of 

55  appropriate  integrated  medical  device  system  standards. 

56  C.1.2  Methodology 

57  For  participants  in  the  focus  groups,  a  context  statement  and  sample  questions  were  used  to  stimulate  their 

58  thinking. 

59  C.1.3  Clinical  scenario 

70  A  Clinical  Scenario  is  a  brief  description  of  a  clinical  situation  or  event.  The  purpose  of  the  Clinical  Scenarios 

71  in  this  document  is  to  provide  background  and  illustrate  the  need  for  the  development  of  technical  solutions. 

72  Two  Clinical  Scenarios  are  provided  for  each  situation: 

73 

74  a)  the  Current  State  typically  describes  an  adverse  event  that  has  occurred  to  a  patient; 

75  b)  the  Proposed  State  is  a  brief  illustration  of  the  improvement  in  safety  and  effectiveness  obtained  by 

76  applying  an  integrated  solution. 

77  C.1.4  Clinical  concept  of  operations  (CConOps) 

78  A  Clinical  Concept  of  Operations  (CConOps)  is  a  more  detailed  description  of  how  devices  and  clinical  staff 

79  could  interoperate  in  a  clinical  environment. 

30 

31  This  description  provides  details  of: 

32 

33  —  The  type  of  equipment  utilized; 

34  —  The  clinical  processes  required; 

35  —  The  type  or  category  of  clinical  staff; 


586  EXAMPLES  Surgeon,  intensivist,  anesthesia  provider,  chief  nurse,  nursing  assistant,  respiratory  therapist. 

587  —  Potential  changes  or  new/novel  equipment  or  workflow  that  does  not  exist  today  but  that  could  improve 

588  the  process  (optional); 

589  —  Benefits  of  the  proposed  process;  and 

590  —  Risk  analysis  of  the  proposed  process. 

591  Each  CConOps  detailed  below  permits  an  improvement  in  safety  and  effectiveness  via  a  specific  solution 

592  implementing  the  Proposed  State. 

593  C.2  Clinical  Examples 

594  Adverse  events/incidents  examples  -  current  method  CSR  abstract  text 

595  Investigation  of  possible  events 

596  Quality  control 

597  Clinician  assessment 

598 

599  Duncan  references!!! 


DO 


601 

602  (informative) 

603 

604  Reference  to  the  Essentiai  Principais 


605  This  standard  has  been  prepared  to  support  the  essential  principles  of  safety  and  performance  of 

606  INTEGRATED  CLINICAL  ENVIRONMENT  as  MEDICAL  DEVICES  according  to  ISO/TR  16142:2007.  This 

607  standard  is  intended  to  be  acceptable  for  conformity  assessment  purposes. 

608 

609  Compliance  with  this  standard  provides  one  means  of  demonstrating  conformance  with  the  specific  essential 

610  principles  of  ISO/TR  16142:2007.  Other  means  are  possible. 
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613  (informative) 

614 

615 
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